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ABSTRACT 

es thesis describes the detailed design of a 
distributed operating system for a real-time, microcomputer 
based multiprocessor system. 

Process structuring and segmented address spaces 
comprise the central concepts arovnd which this system is 
Smelt. ine syStem particularly supports applications where 
peess ing is partitioned into a set of multinle processes. 
One such area is that of digital signal processing for which 
this system has been specifically developed. 

The operating system is hierarchically structured to 
logically distribute its functions in each process. This and 
loop-free properties of the design allow for the physical 
fest ri bution oun system code and data amongst the 
microcomputers. In a multiprecessor configuration, this 


memset cal distribution minimizes system bus contention and 


lays the foundation for dynamic reconfiguration. 
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A. DISCUSSION 


The topic of this thesis is the detailed design of the 
kernel of a real-time microcomputer based multiprocessor 
operating SsyStem. The Kernel comprises a complete, alteit 
primitive, operating system providing support for a large 
number of asynchronous processes. 

The kernel manages all physical processor resources 
thereby providing the user with an execution environment 
relatively free from concern about the underlying hardware 
configuration. The system is capable of performing ina 
real-time environment through the use oye preemptive 
Scheduling to ensure expeditious handling of time-critical 
processing requirements. 

Despite the rapidly expanding capabilities of modern 
Mmerocomputver systems, they still prove to be limited by the 
relatively Slow execution speeds of their microprocessors. 
These svstems generally do not provide the pewer and 
flexibility required to address complex and demancing 
applications. One such area is that cf real-time digital 
image processing. aS 1s &@ particularly démanding 
application area characterized by the requirement to apply 


Significant processing power to a high input data rate. 
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A natural answer to the inadequacies of the lone 
microcomputer is to provide for multiple microcomputer 
systems. Such systems could provide the processing power to 
adequately handle applications which are presently addressed 
Omey Within the domain of »minicomputers and mainframe 
Systems. Fowever, the general purpose microcomputer 
operating system which would control such ea system does rot 
exist today. Most of today’s microcomputer operating systems 
deal only with uniprecessors and, in fact, could not 
adequately manage multiple processors. 

The integration of large numbers of relatively 
inexpensive microcomputers into powerful computer systems 
has been the subject of intensive research in universities 
and industry for several years. As a result, a number of 
multiple microcomputer Systems Such aS Carnesie-Mellon’s Cr* 
[18] nave been built and even more such as the varied 
architectures of Anderson and Jensen [1] have been 
Suggested. The Cm*¥ iS an ambitious syStem with 5¢ processors 
and a complex, custom designed anc built bus structure [i§]. 
Most of the proposed systems require this type of 
Specialized hardware. The primary thrust of this thesis is 
towards a general control structure which can be applied to 
hardware systems that are commercially avéilatle today with 
only very minor or no hardware cevelopment. Thus no serious 
attempt is made to consider alternative hardware 


architectures as a tonic in this research. 





Peecomouuete: hien level operating system design was 
provided by O’Connell and Richardson [11} in their family of 
secure multiprocessor operating systems. This thesis 
eemeerns itself with the detailine of one member of their 
family, a modified real-time subdset. Tne mcdification 
consists of the inclusion of a more general svnchronization 
mechanism, eventcounts and sequencers describded vy Reed and 
Kanodia [13] which replace the more traditional Signal/Wait 
and Elock/Wakeup used in the original desien. 

The system supports multiple asynchronous processes 
Meine the concept of two-level traffic control to accomplish 
processor multiplexing amongst a greater number of eligible 
processes. This édual-level DeccesoC re MULt DlICw Needesien 
allows the system to treat the two primary scheduline 
decisions, viz., the scheduling of processes and the 
management of processors at two Separate levels of 


abstraction. 


Pee oenUOruUnrs OF THE TEESIS 


Chapter II describes the overall design pnilcsophy of 
the Operating system, how multiple processes are 
Synchronized and how their multiplexing on a smaller set of 
MEecessors 15 accomplished. Chapter 3 describes the hardware 
architecture of the multiprocessor syStem in terms of the 
particular hardware suite chosen for this system. Chanter iV 


discusses the details of the kernel desien. The finel 





Chapter presents conclusions and observations that resulted 
meome tm@is €irftoOrt and Sugzestions for further research. Two 
appendices are also provided, an explanaticn of programming 
Mermodoloey fOr “this system and a detailed description of 


the Kernel modules in their present form. 
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[T1. FUNDAMENTAL DESIGN CONCEPTS 


A. DESIGN PHILOSOPHY 


Poultaple processor systems are intrinsically more 
complex then the familiar uniprocessor. Their complexity has 
proven to be the major barrier to realizing the full 
potential of the inherent parallelism available in such a 
system. 

One of the most important components of any computer 
system is the operating system. The operating system manages 
the system’s resources. Thus system performance is 
critically dependent upon its effectiveness. Rowever, 
performance is not just raw computational speed, but is in 
reality the sum-total of numerous attributes. Some of these 
System attributes such as ease of programming, correct 
operation, and the atility to address diverse applications 
are aS important as Speed and efficiency, but too often are 
overlooked. Fecause of this potentially very large set of 
requirements, adequate performance can only be assured if 
the behavior of the system is well understood by the 
designer. Of necessity, this imposes a Strict requirement 
tferesemplicity. 

In this design, the requirement for simplicity is 
satisfied bv utilizing a model bvased on the notion of 


multiple asynchronous processes witn segmented address 
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eco s hisaiS tae central unifying concept which provides 
a Straightforward view of both static and dynémic system 
behavior [4]. The principles of structured system desien are 
also applied to logically organize the operating system into 
a hierarchically structured set of easily understood modules 
whose MimermactiOnomsere clearly specified and strictly 
enforced. | 

The result is a modular, layered operating sytem which 
is both Smaller and eaSier to analyze. Tnis, in turn makes 
it easier to ensure correct operation and provices better 
Seportunity four improving performance through tuning. 
Certain other benefits accrue from simplificaton as well. 
Because the sytem is smaller, less memory is used for 


Operating system code and less processor time is spent in 


its execution. 


Eee GDENTIAL PROCES SBS 


Pooeteminiti Ono: a Process 
Pie CONnCepummot a process has proven to te a 
fundamental and powerful one in the organization of computer 
systems. The rather abstract idea of a process has been 
defined in numerous ways, tut perhaps the simplest is 
offered by J. Saltzer as: 
e+ebasically a program in execution on a processor. Gra 


In considering the above definition, it becomes 


apparent that there are two elements which together 





completely characterize a given process. They are 1) the 
program, consistingé of any se@quentially executed machine 
instructions and data which can be associated with the 
program (usually termed the process” address space) and, 2) 
the execution state of the process which is characterized ty 
the contents of certain processor registers. 

meee ine Process Address Space 

The address Space, Simplistically, provides for the 
encapsulation of a process such that it has no knowledge of 
any other process and no other process has knowledge of it. 
This eliminates the DOSSieo ha ELy or inter-process 
interference simply because processes are unable to escape. 
the confines of their defined address Spaces. 

However, this is rather Lessanctive in that 
processes which are totally ignorant of each other have a6 
hope of co-operating towards the accomplishment cf sore 
greater efoal. In order to mediate this conStréint. one 
desires to allow some restricted (controlled) formr of 
address space overlap (viz., sharing) such that co-operation 
is allowed while still retaining the benefits of protection 
offered by isolaticn. Snaring requires some way cf 
resol eoeeronine bhemmsonared portions of the eddress spece. 
This is greatly facilitated by introducing the noticn of 


memory segmentation. 
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a. Virtual Memory and Segementation 

(orev wememory Is used to implement the concept 
of a per process address space. In Multics [2], each process 
is provided with its own virtual memory for an address 
Space. These virtual merories are completely independent of 
ome dnother. 

A virtual memory consists of a set of Segments. 
Seements are distinct variable s$i2z€ memory objects which 
contain information. Associated with a segment is a set of 
logical attributes used to uniquely identify the segment and 
memcontrol access to it. 

In specifying the set of segments that comprise 
a virtual memory, one may include Segments that are part of 
other virtual memories as well. Thus segments can be shared 
fimeee controlled manner to provide OT Lito mapwOCcess 
communication and co-operation. 

Ry using segmentation to provide ae virtual 
memory environment, the user AS presented with a 
configuration independent system in that he “Sees 4a process 
GamesSouspace that he can consider his own and is not 
dependent on the assignment of physical addresses. 

b. Addressing in a Segmented System 

Addressing in a segmented memory system is 
two-dimensional. That is, a complete address consists of two 
parts. The first is the Seement number. This identifies the 


particular segment of interest. One attribute cf the segment 


18 





is the physical address of the segment’s base. Thus the 
seement can be located anywhere in phySical memory by 
changing the base address. The second dimension of the 
address is an offset relative to the sexyment’s base (the 
peginning of the segment). This serves to access specific 


locations within the segment. 


Pee NT@R=PROCESS SYNCHRONIZATION AND COMMUNICATION 


Wtilizine the parallelism afforded by multiple 
processors requires a mechanism Or inter-process 
communication and Synchronization. at is used for 
controlling the execution of processes and coordinating the 
Sharing of data. ; 

The most widely used synchronization primitives are 
Dijkstra’s semaphores {3] or Saltzer’s Block and Wakeup [17] 
which were used in O’Connell ard Richardson’s original 
design [11]. However, the design decision was mace to use a 
different mechanism which addresses the questions of 
confinement in @ secure system. This is the synchronization 
mechanism based on the eventcounts and sequencers of Feed 


anew Sanodia (13). 
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D. PROCESSOR MULTIPLSXING 


Pe cniniueomor Processor Multiplexing 


Frocessor multiplexine is a technique for sharine 
meerce processor resources among an arbitrarily large number 
of processes. It is accomplished by simulating the existence 
of a larger number of virtual processors. This technique is 
widely used in conventional uniprocessor systems wnere it is 
commonly called multiprogramming. It seeks to maximize the 
use of the available hardware by automating control of 
process loading and execution. It also greatly increases the 
flexibility of a system allowing it to be effective in more 
complex and demanding applications. 

J. H. Saltzer {17] presented one of the fundamental 
works on the subject of processor multiplexing. Fis thesis 
provides an excellent treatise of the salient issues. 

2. Processor Virtualization 

In order to effect processor multiplexing, the 
physical processor resources (those hardware devices that 
execute machine instructions) are virtualized by creating 
abstract processors called virtual processors. 

a. Virtual Frocessors 

HaCnh Spmysical processor posseseé€s some intérral 
memory (registers) whoSe contents describe the processor’s 
state. As part or the processor state, there is a 
Specification of the accessible address Space.which contaics 


the instructions and data used by the processor. 
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Virtual processors are Simulations of 
processors. They can be viewed in essentially the same way 
Peep iyerecal processors in thet they execute the same 
instructions. However, the instruction set cf a virtual 
Preeessor has be€n expended to include some instructions 
which the physical processors do not directly have. TheSe 
include “instructions to ‘load a process, certain 
maeeeronication primitives, system service calls. @tc. 

Nee tal . processors exist enly as abstract 
mmoecessors represented by a data structure. They are used as 
the vehicle for the control and manipulation of processor 
resources. 

es Two-Level Processor Multiplexing 

In this design, there are two levels of trocessor 
multiplexing. This design arose from the existence of 
multiple physical processors. tach of the levels address a 
distinct requirement. One level supports virtual processor 
management, Eiavaat is, the prevision of inter-process 
ween ranization. The other supports the management O34 
physical resources by the operating system. 

Heaes divides the requirements for multiplexing 
mechanisms into two parts. One OW these addresses 
Muti plex@ne virtuel precessors among processes and the 


other multiplexing physical POC SS Sons amone wa ritual 


processors. 
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Seeelne iraific Controller 

The Traffic Controller represents the upper level 
of processor multiplexing (termed Level 2) and provides the 
mechanism for multiplexing virtual processors  arong 
Processes. Thus it 1S Sresponmsible= for imter-—Lrocess 
synchronization. 

emcee ratinwe cOnSideér that @ process, called A, 
Will wish to Synchronize its actions with another process. 
called 8B, such that process E will have to complete sore 
task before 4A can continue execution. Thus A will execute to 
the point where it cannot proceed further and wishes to 
Spada) process E£. when process 2 has finished its task, it 
must notify process Aeof itS coOmplétion so that process 4 
may then proceed. 

This inter-process synchronization is handled at 
the level of the Traffic Controller. When procéss A 
discovered that it could not proceed further, it “gave away 
momeeirtldl processor to some process that could rur. The 
ieerrre controller suspended the execution of process A and 
a new process was bound to the virtual processor. Irn the 
same wav, when 3 completes, viz., it has no more work to 
Detrmcr@eslt will also give itS virtual processor away. 

(oO Memwinnrer = trarrtic Controller 
The Inner Traffic Controller comprises the 
lower level of processor multiplexing (level 1) and provides 


the second set of multiplexing functions. It multiplexes the 
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physical processor among one or more virtual processors. 
While the virtual processors nave identical cavabilities, 
the physical processors may differ in their capabilities, 
aie Z's they may have different attached I/C devices, 
different local memory sizes, etc. The Inner leat £1 
Controller muSt manage the physical resources in such a way 
that the user is unaware of these differences. In 
particular, the syStem’s interrupt syStem is managed ty the 
Inner Traffic Controller. 

If a4 user process calls upon some system service, 
such as disk I/O or I/O for a real-time sensor, it must wait 
moneepeet service to be completed UCefore it can proceed. The 
performance of a system service is considered to be fart of 
the requesting processes. However, it may actually be 
Eweomortea by dnother virtual processor. To control this 
interaction the Inner Traffic Controller ovrovides the 
Beaquered) inter=virtual processor synchronization mechanism. 
Pieeparticular, a™ phySical SyStem interrupt its directly 
transformed into a svncnronization signal to a waiting 
Peebicieeprecessor. This Structure iS particularly important 
for the support of real-time processing. 

4. Processor Multiplexing Strategy 
a. Process State Transitions 
PicVremeeilrustraves [he state tréensitions of 4 
set of processes as a virtual processor is multiplexed among 


them. Some eligible process (one which is in the réady 
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state) is scheduled to run and is bound to the virtvéel 
processor. At this time, the precess makes the transition to 
the running state. As far eas the process is concerned, once 
meeemtersS the rugning state, it is executing. 

At some point in its execution, the process may 
Meeere tO block itself or signal another process. If it 
blocks itself (enters the blocked state), it will give up 
the virtual processor to which it is presently bound and 
wit «=~be out of contention: for processor resources. It will 
remain in the blocked state until some otner process sigrals 
Pt (thus rmakine the transition back to the ready state). If 
the process signals other processes, it will transition from 
the running state back to the ready state from which it may 
be Scheduled to run again. In doing so. it allows the 
Traffic Controller to possibly give tne virtual processor to 
some higher priority process which may te reacy to run. 

Dee wirtudie frocessor State Transitions 

Figure 2 illustrates the state transitions made 
by virtual processors as a physical processor is 
Miptiepeexed. This diagrem is very similar to that of Figure 
1. However, these transitions are not directly observeabdle 
by processes (except as differences in execution times) as 
virtual processor state transitions result from the 
management of physical resources by the operating system. 

In Figure 2, it can be seen that a running 


virtual processor can transition to the waiting state or the 
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ready state. The transition to the waiting state occurs when 
a virtual processor must wait for completion of some system 
service (analogous to the blocking of process A in the 
example given in paragraph a). While in the waiting sté&te, 
the virtual processor is out of contention for processor 
resources until another virtual processor signals it to 
Continue. While in the reedy state, the virtual processor is 


in contention for processor resources and 50 may te 


scheduled tio run on the physical processor. 
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Pewee Le ROGCHSSOR ARCHITSCTURS 


Pee er AARE REQUIREMENTS 


One of the principal design goals of the syStem design 
was to provide for configuration independence. Therefore, 
the operating system imposes tut a few conStraints on the 
hardware that are noted here. 

1. Shared Global Memory 

The operating system maintains system-wide control 
data accessible to each of the processors via shared 
segments. The communication path utilized for sharing this 
data is Shared memory. Thus some Shared memory must be made 
available to each microcomputer in such a way as to allow 
moe mendent access at the level of single memory references. 

Pe ommMmoOcCeSsomeoyuchronization Support 

There must exis some incheware sil pier lca 
multiprocessor synchronization primitive. ThiS can be any 
form of én indivisitle read-alter-rewrite memorv reference. 
This capability is required to implement globai locks on 
Shared data to prevent race conditions as the physical 
processors attempt to asynchronously manipulate shared data. 

ore Recep oceesior Communication 

some method of communication between paigsical 
processors must be proviced. Tnis is satisfied by an ability 


to e€enerate interrupts between the physical processors. This 
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capability is required for the implementation of preemptive 


scheduling. 


B. HARDWARE CONFIGURATION 


mec yr sotem Conti ieurdtion 

‘The hardware sub-system is Cont toured as a 
multiprocessor [1]. The system consists of a numter of 
Single board microcomputers and a globél memory module 
connected by a single snared bus. The system differs from 
conventional multiprocessors fem that each of the 
microcomputers possesses its own local memory. The global 
memory module is Connected directly to tne system bus and is 
the only physical memory resource which is shared by all of 
the processors. The géneral Comsiguration 15 @s20wn 
schematically in Figure 3. 

2. specific Hardware Employed 

The ee bare telcdue hardware Selec Led for this 
implementation i5 based on the INTEL S6/12A single board 
microcomputer [6]. This microcomputer utilizes the INTEL 
6ZE6, a 16-bit general=purpose microprocessor capable of 
@GQirectly addressing a total of 1 mega-byte of physical 
memory. 

a. The &@@86 Microprocessor 

The €G&66 does not Support the notion of explicit 

segmentation. In the &@856, addressing is segment-lixe in 


that base and offset addressing is used. The offsets are 


; 





formed relative to one of the four segment base registers of 
the 8@86: 1) the Code Segment Register, used for addressing 
a pure segment containing executable code, 2) the Tata 
Segment Register, used for process local data, 3) the Stack 
Seement Register, used for the per process stacks, and 4) 
and the Extra Segment Register, typically used for external 
or shared data. 

In the 0&6, a segment can range anywhere up to 
64 kilo-bytes in length. Segments can be placed anywhere 
within the 1 mega-byte address Space of the &€& as long as 
the segment vase is placed on an even hexadecimal memory 
address. Segment access and bounds checking ane not 
Supported. Althougk there is no general segmentation 
hardware, this design effects a segmented address space 
through a combination of operating system support and system 
initialization conventions described in a companion thesis 
by Ross [16]. 

b. The 86/12A Single Board Microcomputer 

The €6/12A i5 a complete computer capable of 
stand-alone operation used as the basic processing ncde of 
the multiprocessor. It 15S a commercial product which 
Satisfies the three basic hardware requirements for this 
operating system. First, possessing a system bus interféece, 
each microcomputer is5 capable of independently accessing a 
global snared memory via the system bus. Secondiv, the E&¢26 


movmeeotoports multiprocessor synchronizaton directly with an 
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imdivisible test-and-set semaphore instruction performed 
under bus locx. Lock semaphores reside in the Shared global 
memory since the system bus must be locked to eénsvure tnat 
ES isi ruction Seemaves scorrectliy. Thirdly, ‘preempt 
interrupts can be generated by using the parallel I/90 ports 
mmovided On Gach microcomputer. This requires connecting the 
microcomputer’s parallel I/0 ports to tne system interrupt 
eryeture. 
c. Freempt Interrupt Fardware Connection 

As with most microprocessors, the &¢@8E€ itself 
does not possess the capability to directly generate 
meperrupts destined for other deomae (tne devices of 
interest here are other processors). The system interrupt 
lines are accessible through a jumper matrix [65] located on 
the microcomputers. The parallel I/0 port output of each 
ISsC &6/i2A is connected to this interrupt jumper matrix. 
Peeemot Interrupts ere then genératéed simply by outputting a 
Single word through the parallel port onto the system 
interrupt lines. The connection is shown in Figure ¢. 

Note that only 4 single interrupt line is 
actually Reg ua ned to implement system-wide rreempt 
moeercupis. in this implementation, four lines are used. 
Poeeseprovides four unique interrupt lines. If more than four 
processors are used in the system, tnen tnese lines are 
multiplexed (viz., several processors share an interrupt 
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d. The System Bus 
Twine elias (Gl is sutibized as the system 
bus. It iS a widely uSed commercial product with a published 
Bet of standards. This bus is specifically designed to 
Support muitiple processors and is fully compatible with the 


[meerecomputers used. I[t is utilized without modification. 


C. EARDTWARE ASSESSMENT 


The commercially available E6/12A single board 
microcomputer was Chosen becéuse it was specifically 
designed to provide support for muitiple processor systems. 
In vsing the operating system described in tne next chapter 
to manaze the microcomputer’s physical resources, this 
microcomputer is entirely suitable for use as a basic 


procesSing node of an effective multiprocessor system. 





Pe eo bED SYSTEM DESIGN 


mM. SPRUCTURE OF TEE OPERATING SYSTEM 


aa S operating system provides a multiprogrammed 
multiprocessor system with segmented process address spaces 
uSing the hardware described in Chapter III. The operating 
system is structured as a hierarchy of three levels [11], as 
follows: 

Tevel 3: Supervisor 

level 2: Traffic Controller 

opel ee Inner Traffic Controller 

The Inner Traffic Controller (Level 1) forms the 
momtom level of the hierarchy. It is ‘closest to the 
meraware and E€ncompasses the major machine-dependent aspects 
of the system. Tne Inner Traffic Controller multiplexes the 
Mmivwstcal processor amongst a pool of more numerous virtual 
processors. 

Residing at the next level (Level 2) is the Traffic 
momuroller, which is responsible for multiplexing virtual 
processors among a larger number of user processes competing 
for resources. The uSeR=access) ble ime LO Ce SS 
communication and synchronization primitives (Advance, Await 
and Ticket) provided at this level allow the user to easily 
address complex system-wide inter-process svnchronization 


requirements. 
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The Supervisor resides at the topmost level (level 
3). The Supervisor’s purpose is to provide common services 
for user processes. In this implementation, it only provides 
a simple higher order language interface to the kernel by 


having a Single entry point into the kernel. 


B. DISTRIBUTING THE OPERATING SYSTEM 


Siemoretne primary concerns in any multiple computer 
System is the issue of performarce. In this type of system, 
a multiprocessor with a single shared system bus, the most 
glaring potential bottleneck is the System bus. It then 
becomes highly desirable to minimize accesses to this 
meeource that must be shared by all of the microcomputers. 

In terms of the design, the described system iS a 
distributed operating system patterned after Multics (12). 
Im particular, the segments of the operating system kernel 
are distributed as part of the address Space of each 
process. In terms of the implementation of this system, the 
performance issue iS addressed by physically distributing 
copies of the kernel in the local memories of each of the 
microcomputers. This allows high-speed access to xernel 
Pumetiors Without necessitating use of the syStem bus for 
eode fetches. 

Thus each Semi ine node can te reearded as 
Senieambenomous ime that each of the processors schedule 


themselves but are still centrally controlled by the set of 
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system-wide data tables. Themen 1S DO Concept of a 
master-slave relationship among individual microcomputers, 
nor are individual kernel functions divided up among them as 


is more often done. Rather the entire kernel is distributec. 


C. REAL-TIME PROCESSING 


Real-time processing involves tne verformance of 
mepercritical processing often related to the control of 
external devices. This application requires that some 
mechanism te emploved to ensure Endt Ge etl a) 
processing is given immediate attention. 

The hardware-supported process preemption mechanism 
employed in the system provides the rapid response required 
for real-time processing. The priority-driven preemptive 
Scheduling technique used provides for expeditious handling 
of processes which perform time-critical functions. These 
Meoeesses are assigned high priorities so that the system 
will preempt other processes of lower priority that may be 
running. Thus when one of these high-priority processes is 
Signalled, it can be immediately scheduled and gain control 


Gmmomocessor resources. 


D. FROCESS ADDRESS SPACES 


The address space of a process is a set of FI/M-&6 


segments: procedures (code), local variatles (data), 
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external data (Shared data), and Stack [12,12]. Fhysical 
memory is allocated to tne segments of a process in such a 
way aS to limit system bus contention, as discussed by Foss 
[16]. In this system, the stack is a key element in the 
management of processes. 
1. The PL/M-86 Stack 

Intel ’s high order language PL/M-€6 [5, 1¢] utilizes 
Stack segments to impvlement per process stacks. Addressing 
of stacks is accomplished ty using three of the €@&6’s 
registers as shown in Figure 5. The Stack Segment (SS) 
Register contains the base location of the stack segment in 
memory. The Stack Pointer (SF) Register addresses the 
current tov of the stack as an offset from the tase of the 
Stack Segment, (the value in the SS kegister). The Ease 
Pointer (BF) eee also holds an offset from tne SS 
Register and is used to establish procedure activation 
meeonds {7..&, 9]. 

Pemltemotack 45 the Address Smace Lescriptor 

In this system, the per process stacks are used to 
maintain process state information. This includes the 
current execution point (when the process iS not actually 
running), the type of return from the ‘kernel reauired for 
the process (normal or interrupt) and the locations of the 
code and data segments. This allows the system to Swap in a 


new address space (viz., do a context switch) by chéngine 
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the value in the SS Register, which is thus used in a manner 
somewhat analogous to the Multics Descriptor Base Register 
ere). 

Figure 6 shows how this information is stored in the 
eeex While a process i5 not actually running on a physical 
processor. The S5ase Pointer, Stack Pointer and Return Type 
Indicator are stored in reserved locétions at the very 
beginning of the stack segment. 

In order to identify the stack segment, and thus 
access the address space of a process, the Stack segment 
base address is used in a dual role. First, a unique base 
address is assigned to the stack of each process which 
provides a maa ue segment for each stack. This base address 
is used for addressing locations within the stack. Secondly, 
the base address serves as a descriptor for the address 
Space of each process. Thus the binding of & processor is 
changed from one process to another merely by changing the 
base address, viz., changing the value in the Stack Segment 


(SS) Register. 


Be SYstTEM PROCESSES 


System processes make up the non-distributed kernel. 
Non-distributed refers to the fact that these processes are 
not distrituted as part of each process” address space. 
Rather they represent various syStem services. System 


processes are used for the management of nardware resources 
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and erecute asynchronously with respect to user processes. 
In this design, all system processes are permanently bound 
to dedicated virtual processors. 
1. The Idle Virtual Processor 

The idle virtual processor provides the physical 
processor with a consistent state when no other virtual 
processor is ready to be run. The idle virtual processor 
assures that physical processors always have some valid 
process address space to execute in, although in this case 
mens Only an idle process that performs no useful work. 

This is assumed by creating for each physical 
processor a dedicated idle virtual processor. The idle 
virtual processors act as default that will only be run 


when no other runnable virtual processors are found. 


F. SYNCHRONIZATION 


Synchronization is required at two levels in this 
SyStem: between processes (at the Traffic Controller level) 
and between virtual processors (at the Inner Traffic 
Controller level). Both levéls use the eventcovnt and 
Sequencer mechanisms [13] described below. 

1. Eventcounts 

Eventcounts are used in this system to allow 


processes to arbitrate access to snared resources. 
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An eventcCcournt is defined by Reed to be: 
"an object in the system that represents a class of events 
that will eventually occur. bak) 
Each eventcount represents a distinct class of events. An 
eventcount is associated with scme typve of event of 
[meercest, ©.2@., Occurrence of a real-time interrupt, a 
buffer becoming full, a data segnent deing read or written 
into, etc. Eventcounts are implemented as sets of positive 
integers aeOnmeec tear ririmaty (toe Limit is actuelly 65,536 
using PL/M-86 “word variables which is adequate’ for the 
applications anticipated) and are used to keep track of the 
total number of such events that have occurred. 

Three operations are defined on eventcounts. The 
value of an eventcount may ve obtained by the READ 
eration. This returns Pie pRresenmtevearue of the eventcount 
aS a positive integer k. From this value, one may infer that 
events @ to kx have already occurred. 

The AWAIT operation allows a process to SuUSpend its 
own execution (enter the blocked state) until a specified 
event has occurred, viz., the eventcount reaches the value 
svecifiedcd. The effect is the same as the conventional Block 
operation or Dijkstra’s “P operator. 

An ADVANCE operation is performed by a process when 
an event has occurred. It increments the valve of the 
eventcount by one to reflect the occurrence of the event. 


This has the effect of signalling the events cccurrence to 
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other processes which were waiting for it by virtue of 
having previously performed an AWAIT operation. The effect 
of an ADVANCE operation is esSentially the same as a Wakeup 
operation or Dijkstra’s "V operator. 

The eventcount signalling mechanism has an eautometic 
broadcast effect which offers an advantage in parallel 
processing. This broadcast capability allows the 
Simultaneous Signalling of several processes which otherwise 
would would have to be signalled sequentially. 

ae SegmienNcers 

There are many situations where accesses to snared 
resources must be totally ordered. Eventcounts alone are not 
sufficient to accomplish this. To provide the capability for 
mutual exclusion, another type of otject called @ sequencer 
[13] is employed. A sequencer is implemented as a positive 
intefer ranging in value from @2 to infinity (as with 
eventcounts, the limit is 65,525). Fowever, a Sequencer is 
used to provide total order to the occurrence of events. 
Initially a sequencer has a value of @. The value increéses 
by one eacn time a TICKET operation is performed on it. 
TICKET is the only operation defined on a s@€qvuéncer. TICKET 
returns a unique monotonically increasing value with each 
call. Thus, a set of events can be totally ordered by the 


TICKFT operation. 
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Seber =-nocess SynenrTronization 

Access to shared resources is easily controlled by 
using eventcounts and Sequencers in concert, as Shown in the 
following ‘producer/consumer example [13]. 

Consider that some hypothetical consumer ~- process 
called Printer uses a single invut buffer in which it fines 
information to be processed (output to the printer). There 
are also an unknown number of producer processes called 
PRODI, PROD2, etc., which have information that they want 
Printer to output for them. Obviously, with a single buffer, 
Only one of the processes can use the buffer at any one 
time. The solution useS one Sequencer and two eventcounts to 
properly mediate access to the buffer using mutval 
exclusion. 

The sequencer Turn is used ty the producer processes 
LO Synchronize their use of the input buffer. The 
eventcounts Full and Empty are used to Synchronize with 
members = den Of the producer processes will execute the 


program shown below. 


PRODI, PROD2, etc. /* Producer progrems * / 
DO; 9 ee 

T = TICKET(TURN)s /* Get a ticket (turn) a 

/* for the buffer x / 

AWAIT (EMFTY,T)3 /* Wait for buffer ready */ 

. /* @rite into the buffer * / 

ADVANCE( FULL); /* Signal Printer that a, 

/* there is work to do x / 


END; /* BO */ 
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Hach of the producer processes first performs a 
TICKET operation on the sequencer Turn to obtain a ticket 
for the buffer. Each time TICKET is called, the variable T 
of the calling producer process will receive a uniave value. 
This value is then used by the producer process as an 
argument for the cé4ll to AWAIT. It is the event (value of 
the eventcount EMPTY) for which the process will wait. When 
that event does occur (the value of Empty, which is advanced 
maerminver, reaches the value specified in the call to 
AWAIT) the process will be unblocked and may then proceed to 
use the buffer. When it has finished, the process will 
perform an ADVANCE operation on the eventcount Full to 
Signal Printer that there is information in the input 
mmrerer. cince Gach producer process uses the same sequencer, 
only one of them at a time will access the buffer. 


The consumer process Printer is programmed as 


follows. 
PRINTER /* Consumer program ay 
Boel = | 1Omebo56; /* Essentially forever 7, 
ARVALTTORULL, 1); /* Wait for a message to be */ 
/* deposited in the tuffer a7, 


/* Perform output function  */ 


Jt that the buffer is nor 


ADVANCE(EMPTY) ; /* Notify waiting processes * 
/* available : 


BND; /* DO */ 
The Printer process synchronizes on the eventcount 
Full (it waits until Full is advanced by some producer 


process that has finished using the buffer). After Frinter 


i 
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Pinisnhes with the buffer, it performs an ADVANCE operation 
Sieuse ECventCcount ampty. This notifies the producer process 
that is next in line that the buffer is now available for 


its use. 


G. TRE INNER TRAFFIC CONTROLLER 


1. Géneral Description 

The Inner iar ie  COntroiler is the physical 
resource manager. It is responsible for physical processor 
multiplexing. ItS principal data base iS a table known as 
the Virtual Processor Map. 

Fach physical processor has its own fixed set of 
virtual processors used in multiplexing. The Inner Traffic 
Controller is primarily concerned only with this set of 
virtual processors. Eowever, the performance of SyStem-wide 
Synchronization requires access to the rest of the virtual 
PeeGesoors aS Well, $0 that SienalS may be sent to other 
physical processors. This is accomplished by maintairing tne 
[emtiead ee rocessor Map aS a central data base containing 
ertries for all of the virtual processors in the system. 
Making it globally available facilitates communication 
between virtual processors on @ system-wide scale. The 
Virtual Processor Map fields are diagrammed in Figure 7. 

The State field reflects the present State of the 
virtual processor and can be any of ready, running, waiting, 


Teenie wenereaay virtual processor iS bound to a process and 
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momeinemeCONteTtion fOr the physical processor. The running 
[ueeak processor is that virtval processor which is 
actually executing a process on the physical processor. The 
waiting state reflects physical fresource management. The 
idle state is assumed by a virtual processor which has no 
process bound to it. The idle state prevents the assignrent 
of useless (idle) work to 4 physical processor. 

Boe PR oGity field of the virttal processor is used 
in scheduling. The highest priority runnable write] 
Buoeessor is Selected to run. This priority is determined by 
the priority of the process bound to the virtual processor. 

The System kEventcount Identifier and System Event 
Awaited fields are used in system level synchronization. 

The Stack Segment Register Velue field defines the 
address Space of the bound process. It holds the process 
address space descriptor. The execution state of the process 
mS Stored in the stack when the procéss is not actually 
running. This is the value which is required to access the 
address Space of the process, viz., it is changed to Swap 
processes. 

The Preempt Pending Flag is used for preemptive 
scheduling. It serves to virtualize a hardware interrupt 
sent to the physical processor. 

2. Virtual Processor Scheduler (Vp Scheduler) 
This module is responsible for maxing the scheduling 


decisions for virtual processors. it selects the highest 
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Deborlty 8§Vintual processor from among the physical 
processor ’s aSSigned set of virtual processors and schedules 
itemeenote that there are two distinct entry poirts to 
Woeocheduler. 

The normal call entry point is uSed by other Inner 
Traffic Controller modules to activate Vp Scheduler when a 
virtual processor gives up the physical processor on its 
own. The preempt interrupt entry point is used in response 
to a hardware preempt interrupt fre. sanotner pmycicadl 
processor. 

Mor a normal call, Vpeochequler Sen > the 
Memeceeeuler return type flag to indicate that a normal 
call-return ‘sequence is to de followed for the executing 
process. The Vp Scheduler return type flag is used to keep 
yeeom Or the mode of entry into Von Scheduler for the 
process. 

Vomoeneduler next se€arcnes through the fixed set of 
virtual processors for the highest priority ready virtual 
processor. In this design, the definition of ready includes 
ie ceomeination “ef an idle state 4nd & pending virtual 
preempt interrupt. This allows an idle virtual processor to 
run so that it may field the interrupt and tind to 4 new 
process. The idle process that wasS bound to the virtual 
prmecessor was ess@ntially useless wp until this point. It 
Meowmproviages aN adaress Space for the virtual processor to 


execute in when binding to a new process. 
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Faving selected some eligible virtual processor, 
PeoeocncoulereaproceedsS tO bind the selected virtual processor 
homme. physi¢al processor. It begins ty unbdinding the 
Gerrenmt ly Yrunning virtual processor. In doing $0, the 
Vp scheduler return type flag, the Stack Pointer Register 
value, and the s54Se Pointer Register value are saved in 
known locations on the process” stack. The process 
execution state had already been saved. 

Einding the selected virtual processor iS begun by 
changing the Stack Segment (SS) Register value to that of 
the selected virtual processor. Once this change has teen 
made, execution has actually swapped to the new process 
aadress space. Einding is completed ty retrieving the 
previously saved Vp Scheduler return type flag for the new 
process, the Stack Pointer Register value, and the Base 
Pointer Register value from the newly acquired stack. 

The last step is to actually check the Vp Scheduler 
meen sty pewehlag to determine the proper type of return to 
execute from Vn Scneduler for this process. If a normal 
call-return is indicated, a normal return will te executed 
back through the calling module. Otherwise, if a preempt 
interrupt return is indicated, an interrupt return will be 
Se wecuLedara nd Check Preempt will see if a virtuél preempt 
interrupt is pending. If a preempt interrupt is found to te 
pending, the Traffic Controller’s preempt handler will be 


invoked. 
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a. Internal Modules 

There is one internal module for the Virtual 
[eereesoor Scheduler (Vp Scheduler). It is used for the 
generation of hardware preempt interrupts. 

eo Hay reint 

ious smodule ss scalled by the Inner Traffic 
Controller’s interface modules Itc_Advance and Send _Preempt. 
mise calléd with one argument, 4a physical processor 
meentifier. iG then generates the required hardware 
moe rrupt. 
5. Inner Traffic Controller Interface Modules 
a4. lLoad_Vp 

This module performs the binding of a new 
meceess tO a virtual processor. It is calied by the Traffic 
Controller Scheduler when a process has been Selected for 
the virtual processor. Load Vp requires two varameters, the 
preerity of the news process and the address space descriptor 
(the Stack Segment Register value). It then swaps in the new 
process onto the virtual processor which is currently 
running. Load Vp only operates on the virtual processor 
which is running on the physical processor. 

Einding is accomplished by updating the Virtual 
Processor Map. The Inner Traffic Controller utility function 
RiGmRetmVD ise used to obtain the identity of the running 
virtual processor. When complete, the virtual processor will 


have a new priority and process acdress space descriptor. 
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Pompe completes by calling Vp Scheduler to schedule the 
virtual processor. 
db. Idle Vp 

ieeetunehion iS Load Vp s counterpart. It is 
called bv the Traffic Controller Scheduler in the event that 
a runnable process is not found for the virtual processor. 
In this case the virtual processor will be idled (enter the 
idle state) and the Idle Process will be bound to it. In the 
Virtual Processor Map, the virtual processor’s state will de 
marked as idle, the address Space descriptor for the Idle 
Process will be entered in the Address Space of Bound 
Process field, and the virtual processor will be given a 
high priority. The idle State ensures that the idle process 
is not actually run (the virtual processor now has a high 
priority) by taking the virtual processor entirely out of 
contention for the physical processor. 

At some later point, the virtual processor may 
be placed back in contention for resources. This will occur 
when the virtual processor is preempted. With the 
combination of an idle state and a pending preempt, the 
virtual processor is treated as a high opriority ready 
virtual processor. This allows the virtual processor to xeep 
busy by expediting its binding tec a process. 

Peewey tdieevp Calls Vp scheduler in ordér to 


give up the physical processor. 





G.. Me Ret Vp 

This iS a utility function which is used by 
mim@erelraiiie Controller and Traffic Controller modules. 
uemeet Vp searches sthe Virtual Processor Map and determines 
the identity of the virtual processor that is currently 
Bunning on the physical processor. It simply checks for the 
virtual processor among the virtual processors assigned to 
the physical processor which is in tne running state. 
Itc _ Ret Vp then returns its result as a fuaction value, 
(viz., as in PL/M) in the AX (accumuletcr) register. It will 
return either the identity of the virtual processor {the 
virtual processor’s index in tne Virtual Frocessor Map) or a 
“not found error code. 

ac. Cneck Freempt 

fomese Meaule is called by Vp Scheduler during the 
execution of an interrupt return. It checxs for a pending 
eeeempt interrupt meant for the virtual processor, which has 
been Selected to run by Vp Scheduler, by checking the 
virtual processor’s Preempt Fending Flag in the Virtual 
Processor Map. If the Preempt Pending flae is set, 
Check Preempt will reset it and call the Traffic Controller 
moamre Tc Fre Pandler. 

The module continuously loops as lone as it 
finds the Freempt Pending Flag set. This is to ensure that a 
new preempt interrupt which might arrive before servicing of 


Pwemast preempt is not lost. 
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e. send Preempt 

thas module is responsible for actually sending 
preempt interrupts. It is called by the Traffic Controller 
Advance module. Send Preempt requires two drguments, the 
identity of the virtual processor which is to be preempted 
and the physical processor to whicn that virtual processor 
is assigned. 

Send Freempt sets the virtval processor s 
Preempt Pending Flee and calls Fdwr_int to generate a 
hardware interrupt for the physical processor. Hdwr_Int is 
not called if the virtual processor to be preempted is 
assigned to the physical processor which is executing 
Send Preempt,. (viz., a physical processor will not issve a 
hardware preempt interrupt to itself). 

i. | pew AWanat 

ince AWai tues One ) of two TaG bts which 
mupbements inte€r-~virtwal processor Synchronization within 
the kernel. It is not accesSible to uSer processes, but is 
used by the system in the management of physical resources. 
It allows a virtual processor to wait for the occurrence of 
a system event. 

It expects two input arguments, the index of the 
eventcount in the System Bventcount Table and the value of 
Phemevent to be awaited. 

Upon being invoked, Itc_Await locks the Virtual 


mEeeecormeepe lt then checks the current value of the 
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emenmtcounmt, obdteined from «the System Eventcornt Table, 
against the value given in the call. If the present value of 
mie eventcount is found to be’less than the value of the 
input argument, then the virtual processor will enter the 
waiting state and give up the physical processor. 

The virtual oprocessor’s entry into the waiting 
State will be reflected in the Virtual Frocessor Map. The 
input arguments will be entered in the Identity of 
Eventcount Awaited and the Value of Eventcount Awaited 
fields. Finally, the virtual processor will relinquish the 
merece processor by calling Vp_Scheduler.: YUpon a return 
Prom Vp Scheduler, the Virtual Processor Map will be 
imwocked. 

g. Itc_Advance 

ipemeavenceras used within the kernel to signal 
the occurrence of system events. It is used with Itc_Await 
monmesvnonronization tetween virtual processors. It accepts 
One input argument. This is the index in the System 
Eventcount Table of the eventcount to be advanced. | 

Tpon being invoked, the Virtual Frocessor Map is 
locked. The System Eventcount Table is then accessed and the 
indicated eventcount’s value is incremented by one. The 
resultant value is then compared against the events waited 
for by other virtual processors which are synchronizing on 


the same eventcount. Those virtual processors whose Value of 





Event Awaited fields are less than or equal to the current 
value of the eventcount are made ready. 

Itc_Advance then calls Vp Scheduler to schedule 
the virtual processor. The Virtual Processor Map will te 


unlocked upon a return from Vp Scheduler. 


H. THE TRAFFIC CONTROLLER 


fmeomeceneral Description 


tiem irartic Controller menages the execution of user 
processes. It presents to the user a system of one more 
virtual processors on which to execute his processes. 

Die ira tt ic Controller’s primary data base is the 
Active Process Table, shown in Figure &. The entry for each 
process in the Active Process Table contains sufficient 
information about the process to enable a virtual processor 
momeoe bound to and execute it. The fields of the Active 
Process Table are explained below. 

The State of a process can be either readv, running 
or blocked. A ready process iS one which is not yet bound to 
a virtual processor but is ready to do so. A running process 
is) one which is bound to a virtual processor and, as far 4s 
the process is concerned, executing. The tlocked state 
reflects inter-process synchronization. A process enters the 
blocked state when it realizes that it can no longer ;jroceed 
and wishes to give up its virtual processor to wait until 


another process awakens it. 
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The Affinity field specifies the physical processor 
meee toe process must execute on. In this system, this field 
indicates the specific microcomputer on which the process is 
euerentiv loaded. 

ime. identity 8r Bound Virtual Frocessor serves to 
identify the virtual processor, if any, that the process | is 
elrently bound to. 

Maem Priority Specifies the priority of the process. 
In this system, priorities range in value from © to 255, 
with 4@ priority of @ being the highest. 

The Loaded List Thread field serves to implement the 
Loaded List of ready and running processes. It contains a 
pointer to the next process in the Active Process Table 
which is loaded on the same microcomputer as this process. 
mae loaded list is ordered by the prioritiés Cue ne 
processes. Thus. this field contains either a vointer to a 
process whose priority is less than or Equal to that of this 
procesS or a nil pointer (viz., the last process on the 
Loaded List). 

The Value Of Everntcount Awaited reflects the event 
for which the process has blocked itself. It contains the 
Poem eunet the process is waiting for the eventcount to 
reach. 

The Block List Thread is used to implement the 
Blocked List. This is a per eventcount list of processes 


which are waiting on the eventcount. 
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The Address Space Descriptor field contains tne 
process address Space deScriptor. This is the identity of 
the process’ stack which contains execution point 
meeeormati.on. 2ne value used here is the base location in 
memory of the stack Segment, viz.. the Stack Segment (SS) 
Register value. 

2. Process Scheduler (Scheduler) 

Scheduler works in essentially the same way that the 
Inner Traffic Controller’s Vp Scheduler does. Fowever, 
scheduler works with precesses. Scheduler can te called by 
Peace,  AWdit, TCc_Pe Handler, Create Evc, Create Seq, and 
Create Frocess. 

emote cCl(S tnhesmienest pritority ready process from 
the microcomputer’s Loaded List to be tound to an available 
virtual processor. Scheduler works only with the processes 
which are runnable on its own physical processor using the 
fixed set of virtual processors for that physical precessor. 

If Scheduler finds a runneble process, the Inner 
Traffic Controller module Load Vp is called to tind the 
selected process to the running Vineeud | DiIvGlecassor . 
Alternatively, if a runnable process iS not found, the 
virtual processor will be idled (bound to tne Idle Frocess 
and placed in the idle state) by @ call to the Inner Traffic 
Controller module Idle Vp. 

ii eomenresent™ form, scheduler has only one entry 


point, a call entry point. There is no interrupt entry point 





as there is in Vp_ Scheduler. This was done as an expedient 
in this design effort. It is desireatle to provide the 
second entry point so that the two schedulers have parallel 
mmmmcuures. BeCause there is no interrupt entry point, there 
is a loop between the Inner Traffic Controller and the 
‘Traffic Controller for the handling of preempt interrupts. 
Moms is due to the call from the Inner Traffic Controllers 
preempt handler Check Pre Empt to the Traffic Controller’s 
Semeenpt handler Tc_Pe fandler. 
a. Internal Modules 

There are two utility modules internal to the 
scheduler that are used only by Traffic Controller modules. 
They are used to simplify the hendling of eventcounts and 
Sequencers. 

(1) Locate_Evc. This “utility returns the index 
of an eventcount in the fventcount Table. It is called by 
Advance, Await and Ticket with (a pointer to) the name of 
paemeventcount. bocate frve then attempts to match the name 
given to it with one in the Eventcount Table. If a match is 
found, it returns the index to the caller in the Ax 
(ieoumiulatven) Register as a function value (viz., aS in 
PL/M). 

(2) Locate Seq. This is the Second Traffic 
Controller ‘utility function. It works in exactly the same 
way that Locate _Evc does except that it Searches for 


sequencers in the Sequencer Table rather than eventcounts. 





5. Trattwe Controller Interface Modules 
a. Await 

Await allows a process to suSpend its execution 
pending the occurrence of a specified event. AWAIT is called 
with two arguments, (a pointer to) the name of the 
eventcourt and the value (of tne event) to be awaited. 

Epon inwexadtlon, AWadlt locks the active Frocess 
Magee anc then calls the Inner Traffic Controller utility 
[memetrron Ite ket Vp to obtain the identity of the running 
virtual processor. This is uSed ina search of the Active 
Process Table to identify the calling process. 

Once the calling process has teen idéntified, 
the current value of the eventcount is comvared to the 
Gwemued “yaine specified in tne call. If the event has not 
yet occurred, (viz., the current value is less than the 
value to be awaited), then the process will enter the 
blocked state. The Value of Eventcount Awaited field in the 
Active Process Table is updated with the value awaited 
argument and the process iS placéd on the eEventcount’s 
Blocked List. If the event has already occurred, (viz., the 
current value is greater than or equal to the value awaited 
argument), then the process iS not blocked but is made 
ready. 

Await next calls Scheduler. The Active Process 


Table is unlocked upon the return from Scheduler. 
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b. Advance 

Advance allows a process to Signal the occurrence 
of an event. It updates the eventcount and signals those 
processes which had blocked themselves for this event. Thus 
Advance is responsible for preemption. 

Advance is called with one argument, (4 pointer 
to) the name of the eventcount being advanced. 

[teeeate loems the ACtive Process Table. Then the 
current value of the eventcourt is incremented. The 
eventcount’s Blocked List is searched for processes which 
had previously blocked themselves for this value. AS 
processes are found that should be awakened, they are made 
ready. An entry in é& temvorary array of physical processors 
is mow made to flag the physical processor, in whose local 
memory the newly awakened process is loaded, for preemption. 
The awakened process iS then removed from the eventcount’s 
Blocked List. 

Once all of -the processes to be awakened have 
peen found, Advance determines which virtual processors must 
be preempted. This is done for each of the previously 
flagged physical orocessors by first assuming that all of 
the physical processor’s virtual processors should be 
preempted. Then the decision is made as to which ones will 
not be preempted. This method greatly simplifies the 
algorithm. First a temporary list (array) of virtual 


processors is initialized to incicate a virtual preempt for 
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each of the virtual processors. The Loaded List is then 
searched to find those processes which should de running. 
The processes which should be running are those with the 
highest priorities that are in either the ready or the 
runnine states. ASSuming there are 2 virtual processors per 
physical processor used for multiplexing, the 2 highest 
Meeority ready or running processes in the Loaded list 
Should be running. Any lower priority processes that 
actually are running should be preempted. Advance determines 
which of the processes that should be running élready are 
running and deletes their virtual processors from the 
preemption list (resets the preempt flag in the arréy). What 
will remain at the end are those virtual processors that are 
noe preempted. 

The next step is to actually issue the preempt 
Peer nupts. The temporary preempt list is checked and if a4 
preempt is indicated for a virtual processor, the Inner 
tieaeone Controller module Send Preempt is called to actually 
issue the preempt. 

Advance next readies the calling process and 
Pwesmeoeneduler. Upon the return from the call to Scheduler 
the Active Process Table is unlocked. 

ee Tieke t 

Ticket returns a unique sequencer value with 

every invokation. The value returned will always te one more 


than the last value returned. 


63 





Tt is called with one argument, (a pointer to) 


the sequencer name. When invoked, Ticket asserts the e2lobal 
lock on the Active Process Table, effectively locking the 
sequencer Table. Ticket then calls Locate Seq with the 
pointer to the sequencer name given to it as an input 
argument and gets back the index of the Sequencer in the 
Sequencer Table. It then obtains the sequencer’s value which 
is to be returned to the calling module in the Ax 
(Accumulator) Register following standard FPL/M conventions. 
Before returning, ticket increments the value of the 
Sequencer and unlocks the Active Frocess Table. 

Note that Ticket does net call Scheduler like the 
Other synchronization primitives Advance and Await. Ticxet 
returns immediately from a call. 

d. Read 

Read returns the current value of an eventcount. 
It is called with one argument, (a pointer to) the name of 
the eventcount. 

When called, Read locks the Active Process Tele, 
so as to lock the Eventcount Table. It then calls Locate Eve 
Mime bealin the index of the eventcount in the Sventcount 
Table. With this index, Read obtains the value of the 
eventcount and returns the value in the AX (Accumulator) 
Register following normal PL/M conventions. Pe OF to 


returning, Read unlocks the Active Process Table. 
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eee en tandler 

This module serves as the virtual jpreempt 
meer rupt Entry point into Scheduler. It is called by the 
Inner Traffic nontroller’s Vp Scheduler in the course of 
handline Pecempre 2 mverrupts. 

fe re handler calls Scheduler to find the highest 
priority ready process to bind to the pre-empted virtual 
peecessor. 

i. . CREA tem Cc 

This module creates an eventcount for a user 
process. Creete_ Eve is called with one argument, (a pointer 
to) the name of the eventcount to be created. 

Upon being invoked, Create_Eve locks the Active 
Process Table, which effectivelv locks the Eventcount Tatle. 
It then calls Locaté_Eve to determine whether or not the 
eventcount had already been created. This is to avoid making 
duplicate entries (since each process which will use the 
eventcount must declare at least the name}. it tae 
eventcovnt had not previously been created (viz., no entry 
is found in the Eventcount Table with the Same nare as giver 
in the input argument) then an entry is made in the 
Eventcount Table. The name is copied into whe Evenweownt 
Table and the eventcount’s current value is initialized to 
CmmOtmierwase, no weltry is made. Lastiy, it wnlocks the 


Aopowiemerocess Table prior to returning. 
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Beeereate Sed 

This mocule creates a sequencer for ae user 
process. Create Seq performs in exactly the same way as 
Create _Evc (paragraph f) except that it creates sequencers 
meoer than eventcounts. 

leeerea fe orroGcess 

Create Process provides the capability to 
dynamically create processes. It is called with one 
argument, a pointer to a process parameter tlock containing 
all the information necessary to initialize the process’s 
stack and enter the newly created process into the Active 
Process Table. All of the process’s Segments had previously 
been loaded into memory by the system loader, Foss [16]. 

Create Process first locks the Active Process 
Table. It then creates the initializaton stack frame. The 
moeess parameter block contains al? of the initial régister 
values Gy iez < initial values for all of the &€&6’%s5 
registers) for the process. Thesé€ are stored in the 
initialization stack frame; the location of the stack is 
specified in the Process Parameter Block. The next step is 
to create the Active Process Table entry for the process. 
The affinity, priority and Stack Segment (SS) Register value 
are then entered in the Active Process Téble. Lastly, 
Create Process determines where this process should _ be 
inserted into tne Load List based on its Drwori ty. 


Create Process inserts the process into the Load List (viz., 


Or 
OQ? 





sets the Load Thread in the Active Process Tattle) 
Momearayvely ahead of the first process it finds in searching 
down the LoadSList whose priority is less than or equal to 
the newly created process. Finally, the Active Frocess Table 
meeumloczed and ex€cution returns to the caller. Note that 


the Scheduler is not called. 
I. THE SUPERVISOR 


In a general-purpose operating system the Supervisor 
mmovaces common services such as library routines, linkers, 
various development tools and a file sytem. it also acts as 
the interface between user programs and the xernel. 

1. General Lescription 

At this state of the design, only one module resides 
at this level, a higher order language interface to the 
operating system kernel. This module (called the Gate) is 
constructed such that it is the only operating system module 
that tie user must link to his processes to access kernel 
mimGtLOns. 

The Gate contains the actual linkages (viz., elobval 
procedure declarations) for all of the kernel functions. 
This allows the user to directly call on various kernel 
services without using absolute addresses that can change as 
the kernel continues to be developed. Tnis structure allows 
the users and the overating system developers to continue 


their work independently without requiring the users to 
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continually change their programs to accommodate changes in 


eee merne]. 
pee euneryisor Invocation (The Gate) 
iemecencemicmeactualiy a set of flobal (viz., PL/M 
PUBLIC) procedure declarations which the Meier programs can 
call directly. Bach of the user accessible kernel functions 
is represented by one of See “procedures. In reality, 
they sSimovly set up the required parameters and use a trap 
feature to effect the call to the “real” procedure of the 
same name residing in the Kernel. 

The Gate is written in assembly languége because of 
the stack manipulation that must be done to enable the trap 
handler to 1) determine the correct xernel procedure to 
call, and 2) properly pasS parameters to the kernel 
Meoceaures. The trap handler in the kernel is an assembly 
language module as well. If the trap handler were written in 
PL/M, parameters would have to be somenow given to it 
Ewememecitiy prior to its calling on the kernel procecure. 
Since the trap handler is reached by an interrupt rather 
than a call, this is not possible. Instead, the parameters 
are moved on the stack to a position where they becore 
parameters for the call by the trap handler to the kernel 
procedure. 

This has the effect of de-coupling the user from all 
of the operating syStem modules below the level of the 


Supervisor. 
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V. CONCLUSIONS 


A. SUMMARY OF RESULTS 

The principal goal of this effort is the developrent of 
a multiple processor system. A parallel development effort 
in secure syStems, Reitz [18], utilized the C’Connell and 
Richardson design as the basis for the Kernel of a secure 
Someurer System utilizing the Zilog Z&@@é@ microprocessor. 
The detailed designs of the kernels of bdotn of these systems 
is nearly identical, at least at the level of kernel module 
interfaces. In both development efforts, no conceptual 
problems were encountered. Thus the O0°Connell and Richardson 
design has Keen Pounds Om DemmCONS | Sbemt 10F multiple 
processers and secure computer systems. 

System initialization [16], introduced a number of 
design changes. Eowever, these had no adverse effect on the 
design or the system. Their integration is not a simple 
matter as tney impact on the Stack format, and the deSiegn of 
the process scheduler and virtual processor scheduler in 
that the accommodation of preempt interrupts iS Somewhat 
iomesadirricult. 

Another of the objectives is to test the viatility of 
utilizing general-purpose, commercial microcomputer systems 
as the baSic building blocks of multiple computer systems. 
It has been found that sufficiently developed microcomputer 


systems are available in industry. hurtoer, se was 
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determined that enough hardware support (busses, I/0 
devices, peripherals) is available to construct multiple 
eomputer systems without major hardware development efforts. 

The State OF the art in microcomputer software 
development was found to be leSS amenable. Such useful tools 
as high level languages, assemblers, etc. are available but 
they are generally limited to usé with uniprocessor 
feeevopnental systems. Additionally, most commercially 
available software development tools are highly machine 
dependent. Specifically, they require low-level monitors or 
special hardware that are only available on a develonment 
System. Thus there is little hope of easily modifying these 
tools to run on a different system than was interded ty the 
mendor, particularly since details of their structure and 
operation are proprietary. 
A. FURTEER RESEARCF 

further development work is still required. This 
mieuees tne final construction of the Gate and tee 
inclusion of two non-distributed kernel processes for I/0 
and memory management. These kernel processes provice for 
the virtualizaticn of memory and I/O resources with which to 
achieve the goal of configuration independence. 

The present deSign utilizes the test-and-set Semaphore 
operation to implement global locks on kernel data bases 
(viz., the Active Process Table and the Virtual Processor 


Map). This mechanism (supported by the PL/™ built-in 
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procedure Lockset [5]) is a spin-lock witun cvotentially 
rommericant Impact Om System bus traffic. This mechanism 
sould be replaced inee poe sinner. Irathaic. Controller 
Seremnponization primitives wherever possibie to avoid the 
overhead of busy-waiting . 

Mimemecetatled design is considered to be only a first 
step in the develovnomert of a general-purpose mrultiple 
microcomputer system. O’Connell and Richarédson’s design 
offers some exciting opportunities to pursue development 
Saeeortvs in the areas of securé computer systems and fault 


tolerance. 
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APPENDIX A —- PROGRAMMING 


A. INTRODUCTION 


This appendix is designed to be a practical introduction 
to progremming methodology for tnis system. 

Because there are multiple processors, a hnumrber of 
concepts and methodologies will necessarily the introduced 
meen Mmdy at first be uncomforteatle. This is especiélly true 
Mmecne 15 firmiy entrenched in the traditional concepts of 
miemmonolithic, sequential progrém structure. However, as 
one Gees) the “transition to tne concepts of process 
Sruevuring, it will be seen to be a naturél anproach to the 
cevelopment of complex software systems. Additionally, it is 
Bescential to the effective use of multiple processor 
systems. 

Parallelism immediately presents the programmer with an 
entirely new set of complexities. Fe is not limited to tne 
Eeerptctly sequential execution of program statements in a 
Single program. Exercising control over the order and tirine 
of execution of multiple processes becomes a major part of 
the - proeramming EewOrtU. Miter —precess Synchronization, tre 
mechanism by which processes are cortrolled, is tne most 


[eermewt concept which the user will be required to dee 
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With. However, the synchronization primitives tuilt into the 
operating system are designed tc make this as simpie and 
Biraientforwarc as possible. 

It is assumed that the primary programrine language for 
this system will be Intel’s FIi/M-sSé (2, 1¢]. This is a 
powerful, block structured high level language designed for 
systems programming. This appendix is written assuming that 
the reader will program in PL/M-&6 and is familier with its 
terminology and notation. All of the Examples maxe use of an 


informal PL/M notation. 


feeeeres PROCESS STRUCTURE 


momctder the rather typical PL/M progrem module of 
Figure 9. It contains three procedure declarations and some 
mainline statements. #acn of the procecures will execute 
when called from the mainline and, upon comvletion, will 
return control back to the mainline. 

A single program is what most users are familiar witha 
and is a structure which can be dealt with easily. Eowever, 
momeeve computing task grows to anv real Size and comnanlexity, 


this single program grows equally large and complex. Tre 


ct 


result is a huge program with a myriad of procedures tha 
can only be called sequentially to perform necessary 
munmctions. Thus this structure does net allew taking 
advantage of the performance edin that perallel processing 


ean offer. 
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Propram Module A: Do; 
MicerRUCEDURE /* Declaraticn */; 
DO; 


END; 
PO peyeeenocedune Al */ 


Herel rOCmoURH; /= Dechkaration *“/ 
DO; 


BND; 
END; /* Procedure A2 */ 
FE 


AZ: PEFOCEITURE; /* Teclaration */ 
; 


} 
UND; /* Procedure Ag */ 
Beye /* Lezgin Mainline */ 
GAL Lopate; 
CALI A2; 
GALL AS; 


END; /* Mainline */ 


END; /* Program Module A */ 


EXAMPLE PL/M-86 PROGRAM 


Figure 9 
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The principal advantages of the process structure lie in 
bee ability to mtilize multiple processes and ie 
imeependentiy construct individual components of software 
Subsystems, viz., processes. Rather than using a2 single 
meogeess to accomplish the entire job as in Figure 9, the 
overall task can be partitioned and accomplished ty a number 
Of Smaller cooperating processes. Hach of these processes 
can be smaller than tne single monolithic program and so is 
Gasier to design, implement and test. This allows entire 
processes (each a distinct program) to be developed and 
tested semi-independently in a manner similar to tne 
development and testing of individual procedures in ée single 
PL/M program. 

moeerel over processing functions is also much more 
flexible. One is not forced into a Strictly sequential 
series of procedure calls. Many processes can be allowed to 
execute in parallel. which can bring about dramatic eains in 
Oyeraii performance. 

Figure 16 is a simple example cf the flow of execution 
in a svstem with three processes. The three processes 
perform exactly the same functions as the three procedures 
of Figure ¢ ard so bear the same names. In this example the 
pmuocesses execute sequentially, one after the other in a set 
order. Processing goes on forever in this loon. Frecess A2 
Will only begin executing after it hes teen somehow 


“signalled by process Ail. The same is true of process AG 
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Meese exeCuchon 15 Ssynehronized with process 42. Obviously, 
fee MUSt be some control mechanism that é@lliows these 


processes to do this. 


Ce INTER-PREOCSSS SYNCERONIZATION MECRANISMS 


Miewavility to synchronize the ex@cution of processes 
throughout the system, (irrespective of which microcomputer 
they are loaded on), is the cornerstone of the power and 
Meemeility or this system. To accomplish this, process 
mameuronization is based on the notion of events. 

1. Events 

An event is anything that one considers significant 
momcan direct, in some faSnion, the computer to respond to. 
As an example, consider a clock which indicates a time of 
twelve o’clock. The computer has no inherent conception of 
time. As far as it is concerned, time tiay be nething more 
cmea VYelue in some register. In Some way, then. time must 
be defined for the computer. This is accomvlished Dy 
translating the occurrence of twelve o’clock into an event. 
When the event OCCUTS , the computer recognizes that it is to 
mesmona in some specified manner. 

Events are defined so as to he very general in 
nature. They can be vsed to represent the comvletion of a 
Eecerdm, a5 in the cOmpletion of process Al in Figure 1¢ 
which started tne execution of process Ae. They can 


Mommesem peevirtidiily anything of interest to the programmer, 
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Meeereest anything thet he can identify as being of 
Somiiticance. 
2. sventcounts and Sequencers 

Eventcounts and Sequencers allow processes to 
Ememenronize with each other somewhat ier Generel ver To 
Synchronize directly, a process would have to somehow 
i@entify the other processes with which it is synchronizing 
(rme., eGexplicitly signal a vrocess by name). This would 
require the naming of individual processes or sore Similar 
meer tirication scheme. 

Rether than using a process naming scheme, the 
individual processes ‘agree’, in a sense, to cooperate dy 
using a common set of memory objects called eventcounts and 
sequencers. In this way, even thoveh the processes must know 
the names of the eventcounts and Sequencers that they uwusé, 
they are mot required to know anything at all atcut each 
other’s identities. In fact, a process need not even know 
how many other processes will tbe synchronizing with it. 
This offers some advantages in parallel processing. 
Processes trat synchronize with eventcounts do not have to 
know how many other ovrocesses will also use the same 
eventcounts. ThisS means that fewer coding changes will be 
required when, for example, a single process is partitioned 
into several processes all executing in parallel. All of the 


e? 


new. Processes Willi synchronize cn the same eventcourt so 
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Bea nO Cidteses are required in tne process that originally 
Synchronized with the Single process. 

Eventcounts are used to xeep track of the occurrence 
of specific events. They are managed for the user by the 
system. Eventcounts are implemented as FI/M-E6 word 
memreble€s ranging in value from @ to 65526. Sequencers are 
also implemented as FL/M-E6 word variables ranging in value 
from @ to 65536. However, sequencers can be used to impose 
Gmeeorder on the occurrence of events. They are thus used 
with eventcounts to provide for mutual exclusion. 

3. Hventcount and Sequencer Teclarations 
a. Declaring Eventcount and Sequencer Nares 

Eventcounts ana sequencers are named using a 
byte array of alphanumeric characters. The format for 
foomerime an ECventcount or sé€guencer name is given in rigure 
11. Note that the names are constants, not variatles. Once 
declared, a rame must not Change. Eventcount and sequencer 
Memes consist of 5 characters followed Ey @ per cenit symbol 
(4). Note in Figure 11 that the name of the byte array rust 
bemtme same as the string constant é€Given in tne TATA 
Initialization. This allows the user to reference the 
eventcount or sequencer by name and allows the operating 
Syouem te@midemtafy it. 

Remember that the names of eventcounts and 
Sequencers rust be declared in exactly the same wey in e4acna 


PL/M-86 module in which they will be used. 
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t. Passing Fventcount and Sequencer Names 
When calling the operating system 

Synchronization primitives, eventcount and sequencer names 
are always passed as FI/M-&6 location references using the 
"G operator. As an example, consider that a byte array 
called ‘NAME1° holds the string “NAME1%” (note that the "% 
Symbol is only a delimiter and is not considered to bé part 
of the name). To pass the néme in a call to an operating 
System synchronization primitive, then, tre parameter 
"@NAMEL is used. With the pointer so given, the operating 
system can read the name directly from the array. 

c. Creating =ventcounts and Sequencers 

Before an eventcount ora Sequencer is used, the 
opereting system must be informed cf its existence. This is 
meeomolrsmed by a cCall to the operating system procédures 
CREATESEVC (for eventcourts) and CREATESSEC (for 
sequencers). The format of these operations is shown in 
Figures 12 and 13. There is only one argument for either of 
miemearis, the pointer to the previously declared name. when 
created, an eventcount or a sequencer will always te 
initialized with a starting value of @. 
Cee ovmenronization 

Eventcounts and sequencers are utilized by means cf 

a set of operations which may be performed on them. The user 


cannot directly perform operations on either eventcounts or 
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sequencers, but rather calls on certain operating system 
Mmeamicvives to 4@0 these for him. 
a. Operations on Eventcounts 

There are three operations that one cén perform 
on eventcounts. They are ADVANCE, AWAIT and READ. ADVANCE 
and AWAIT are untyped procedures. FREAD is a value returning 
typed procedure (function call) that returns a FL/M-& word 
value to the calling vrocess. 

An example of a READ operation is given in 
Figure 14. The RAD operation allows the user te obtain the 
current value of a specified eventcount. FEAD returns tne 
eventcount’ s value in the AX hegister (in accordance with 
rormal PL/M-&6 conventions). Thus a process calls FEAL with 
the rame of the eventcount as the argument and gets bacx the 
eventcount’s current value. Note in Figure 14 that the 
current value of eventcount EV3NT is returned to the 
user-defined word variable “WOEZDSVARIABLZ . 

Pic ave £ TOMere tt Onn flare 1S. 1s YSed str 2 
process to block itself (suspend its execution) until the 
SEventcount reaches the velue specified in the call. AJ#AIT 
requires two arguments, the eventcount name and the event 
(actually the valve of the eventcount) to wait for. The 
value for which the process will wait must be a PI/¥-@6 word 


value. This allows tre process to synchronize itself with 





WORISVARIAPLE = READ(GEVENT); 


THS READ OPERATION 


Figure 14 


CALL AWAIT(GEVENT ,VALUESTOSAWAIT ); 


THE AWAIT OPSRATION 


Figure 15 


CALL ADVANCE(G@EVENT); 


THE ADVANCE OPSRATION 


Figure ié 


WORDSVARIABLE = TICKET (GNAMZEi);3 
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meet epeo@cesses by waiting, for instance, until a set of 
meme 15 ready for it to use. 

Mae AUVANCE operation, Figure 16, is used to 
Slgnal tne occurrence of an event. ADVANCE onlv requires one 
argument, the name of the eventcaurt to be advanced. mee it 
is called, it will cause the value of the eventcount to te 
incremented by one. The operating syStem will then rroceed 
to unblock those processes that were waiting for the 
Beemitcount to reach the current value (by virtue of having 
previously called AWAIT). 

Pee Operations on Sequencers 

There is only one operation thet can te 
pencormed on sequencers. It is celled TICKET, Figure 17. 
TICKET is a value returning typed procedure (function call) 
Similar to the BEAD operation for eventcounts. Eowever, 
meer, returns to the caller a unique Sequencer value. The 
current value of the sequencer is returned to the caller ard 
then the sequencer is incremented by one for the next caller 
tamemea LICKST operation is performed on it. This will be 
true irrespective of how many different processes perferm 
the TICEET operations. In thiS way TICKET provides the 
totally ordered set of values for use by multivle processes 


in effecting mutual exclusion. 
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S.- oynchrenization Examples 
a. Sequential Processing Example 

Figure i8 provides a detailed example of how a 
Meee o> WOUld be programmed to actually create anc use 
eventcounts for synchronization. The program shown here is 
actually process Al of Figure 12. 

Tevcminenoan tae flow lof Gomtrol in Figure I1¢, 
it can be seen that process A2 will begin execution when 
Seemailed by Al. Similarly process AS will tegin when 
Signmalled by Ad. Finally, when A3 signals its completion, 
' the loop starts over again with process Al. This is 
reflected in the sample program for process Al, Figure if. 
Here two eventcounts are declared and created, ENDA1L and 
"ENDAS. Eventcount ENDAl is used to synchronize with 
process A2. Specifically, ENDA1l refers to the evexrt 
corresponding to the completion of A1l’s processing task. The 
occurrence of this event iS Signalled to process A2 through 
the Advance operation performed on eventcount ENDAL (located 
at the end of the “To Forever loop). The result of the 
Advance is to start the execution of process Ad. After the 
call to Advance, process Al will loop back to the call to 
Await with an awaited value of 1 this time and (if process 
AS has not yet advanced ENDA3) will wait there. 

Process A2 iS programmed as shown in Fieure 15. 
Note that it first calls Await with the eventcount 2NDA1 and 


an awaited value of 1. This is in contrast to the awaited 
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FROGRAM MODULE Al: DO; 


/* Teclare Eventcounts */ 
mmeenaek ENDAI(6) BYTE DATA (°ENDA1% 7); 
DECLARE ENDAS(6) BYTE DATA (’ENDA3%"); 


/® Declare a local word variable */ 
DECLARE A1SAGAIN WORD; 


/* Declare Synchronization Primitives */ 
CREATESEVC: PROCEDURE(EVENTCOUNT) EXTERNAL; 

DECLARE EVENTCOUNT FOINTER; 
END; 


AWAIT: PROCEDURE(EVENTCOUNT, VALUE) EXTERNAL; 
DECLARE EVENTCOUNT POINTER, 
VALUE WORD; 
END; 
ADVANCE: PROCEDURE(EVENTCOUNT) EXTERNAL} 
DECLARE EVENTCOUNT POINTER; 
UND} 


Poeeeein Mainline */ 
AISAGAIN = @; /* To start execution immediately */ 
Greer  OREATSSEVC(GENDA1); /* 
CALL CREATESEVC (GENDAS); 


mo WEILE 1; /* Do Forever */ 


/* Check to see if processing should begin */ 
CALL AWAIT(GENTAS,A1LSAGAIN); 


/*®* ProcesSing completed so notify process A2 */ 
CAIL ADVANCE(@ENDA1); 
/* Increment the value to await */ 
A1SAGAIN = AISAGAIN + 1; 
END; /* Of Do Forever */ 


END; /* Module */ 


EXAMPLE CODE FOR PROGRAM Al 


Figure 1€& 
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PROGPAM ‘MODULE A2: DO; 


/* Declare Eventcounts */ 
WHOPARE SNDA1(6G) BYTE CATA ( “ENDA1%’)3 
DECLARE ENDA2(6) BYTE DATA (°ENDA2%°); 


/* Declare a local word variable */ 
DECLARE A2SAGAIN WORD; 


/* Declare Synchronization Primitives */ 
CREATESEVC: PROCEDURE(EVENTCOUNT) EXTERNAL} 
DECLARE EVENTCOUNT POINTER} 
END} 
AWAIT: PROCEDURE(EVENTCOUNT, VALUE) EXTFRNAL} 
DECLARE EVENTCOUNT POINTER, 
VALU? WORD} 
END; 
ADVANCE: PROCEDURE(EVENTCOUNT) EXTERNAL; 
PECIARE EVENTCOUNT POINTER; 
END; 


/* Rezin. Mainline */ 
Ne>NG@AIN = 1; /* To start Execution after process Al */ 
CALL CREATESEVC(GENDA1); /* 
CALL CREATESEVC(GENDA2) 3 
DO WHILE 1; /* Do Forever */ 


/* Check to see if procesSing should beein */ 
CAIL AWAIT (GENDA1,A2SAGAIN) 3 


/* Processing completed so notify process AS */ 
CALL ADVANCE(GENDA2); 
/* Increment the value to await */ 
A2SAGAIN = A2SAGAIN + 13 
END; /* Of Do Forever */ 


END; /* Module */ 


EXAMPLE CODE FOR PROGRAM Ae 
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PROGRAM “ODULE AS: IC; 


/* Declare Eventcounts */ 
DECLARE FNDA2(6) BYTE DATA (’ENDA2%“)3 
DECLARE ENDA3S(6) BYTE DATA (°ENDAZ%’); 


/* Declare a local word variable */ 
DECLARE ASSAGAIN WORD; 


/* Declare Synchronization Primitives */ 
CREATESEVC: PROCELURE(EVENTCOUNT) EXTERNAL; 
DECLARE SVENTCOUNT POINTER; 

END; 

AWAIT: PROCTDURE(EVENTCOUNT,VALUE) BXTERNAL; 

DECLARE EVENTCOUNT POINTER, 
VALUE WORD; 
END; 
ADVANCE: FROCEDURE(EVENTCOUNT) EXTERNAL; 
DECLARE EVENTCOUNT POINTER; 
ENT; 


/* Begin Mainline */ 


ASSAGAIN = 1; /* To Start execution after process A2 */ 
CALL CREATESEVC(GENDA2); /* 
CALI CREATESEVC(GENDAS) ; 


Doman liLe 1; /* Do Forever */ 
/* Check to see if processing should begin */ 
CALL AWAIT(GENDA2Z,A3SAGAIN); 


/* Processing completed so notify process Al */ 
CALL ADVANCE(CGCENDAZ);3 
/* Increment the valve to await */ 
ASSAGAIN = ASSAGAIN + 1; 
Ebvo; y= Cf Do Forever */ 


mioray* Module */ 


FXAMPL= COLE FOR PROGRAM Ad 
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foe ot 0 used by process Al in its initial call to Await. 
iamiseeprocesS A2 will wait at this point until signalled by 
process Al (if process A2 begins executing before process 
Al). After Al performs an Advance on eventcount ENDA1L, 4&2 
Will perform its procesSing and when complete will Signal 
process Ad to begin via an Advance operation on the 
eventcount ENDAS. As with process Al, it will then loop tack 
to the Await operation and will be suspended until Ai once 
again signals it to continue. 

Figure 2e€ shows the program for process A3. 
Process AS performs an initial Await as the others did and 
when its processing tasSx hasS been completed, it signals 
process Al to begin the “loop” again via an Advance 
operation on eventcount ENDAS. 

These three processes are intended to 
demonstrate the mechanics of synchronizing with eventcounts. 
As can be seen, the operations used in all three of the 
processes are very similar. The réal differences lie only in 
the specific eventcounts that each process uses in the célls 
to Await and Advance. Note, however tnat each process 
performs the Await opé€ration at a point that ensures the 
process will be synchronized with its comvanion processes 
even if the process begins “out of order. This is required 
to avoid confusion since there iS no guarantee that the 


mipcieot tie taree processes to begein executing will be the 





one intended by the programmer to execute first ‘viz., Al in 
this example). 
B. Parallel Processing Example 

Suppose that instead of tne simple sequential 
eeecutioOn of processes, aS in the above exemple, one wishes 
to execute processes in parallel. Tne eventcount mechanism 
provides the capability to synchronize parallel processes in 
(mechanically) the same way that sequential processing is 
accomplished. 

Consider again the trree processes Al, Ad, and 
£3 from the previous example. This time the programmer notes 
that processes A2 and AS both depend on input data (a set of 
ie, er coefficients, for example) from process Al. However, 
he also notes that neither process A2 nor AZ alters the 
input data (they only read it). Thus processes A2 and A@ 
meeome Candidates for parallel execution since théev both 
nave a common event upon which to begin execution (the point 
where the input data becomés avéilable) and thev 4o not 
depend on each otner. Note, however, they must reside in 
different microcemputers for their execution to actually 
@ecur in parallel. 

The desired flow of execution is showr in Figure 
mpeeinplementing the parallel execution of processes Ae and 
AS iS actually a simple task. Only process A@ need be 
Changed. Processes AZ and AS await tne same value of a 


common eventcount rather than different ones. This the 


9¢ 





Se 6 
Deak Erocessing 


Az 


AS 


Loop back 
FO Stare 


FLOW OF CONTROL IN PARALLEL PROCESSING 


rigure 2i 


J 





PROGRAM MODULE AS: BO; 


/* Declare eventcounts */ 
/* Eventcounts ENDA1, ENDA2 and ENTAS 


/* Declare a local word variable */ 
DECLARE ASSAGAIN WORD; 


DECLARE ENDA1(6) BYTE DATA ( °ENDA1%’); 
DECLARE ENDA2(6) BYTE DATA ( “ENDA2%”); 
DECLARE ENDA3(6) BYTE DATA (’ENDASZ’);3 


/* Declare synchronization primitives */ 
ye Advance and Await = 


/* Begin Mainline */ 
/* Create the eventcounts */ 
ASSAGAIN = 1; 
DO WEILE 1; /* Bo forever */ 
CAIL AWAIT(GENDA1,ASSAGAIN); 


[ee Perform processing ay 


/* Processing of both A2 and AS complete */ 


CALL AVAIT(GENDA2,A3SAGAIN)} 
CALL ADVANCE(QENDAS); 


/* Increment the value to await */ 
ASSAGAIN = ASSAGAIN + 1; 


ZND; /* Of Do Forever */ 
UNDS /* Of Module */ 


PARALLEL PROCESSING SXAMPLE PROCESS AS 


Figure 22 
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Beoubt Cf @ Single Advance on the eventcount will te to 
Simultaneously signal processes A2 and A3. 

The operations performed by process A3 iS Shown 
fmerPigsure 22. Process tees Still peauired to werform its 
meecesSing first to provide inpvt data for processes A2 and 
A3. Thus process Ai performs an initial Await operation on 
the eventcount wuNDAS with an awaited valve of @, and since 
the eventcount iS initialized to a value of @ upon creation, 
AiewWill be allowed to continue. Processes A2 and AS both 
Mere orm their initial Await operations on the eventcount 
ENDA1 using the same awaited value (they eacn wish to begin 
processing when the set of input data becomese available). 
Eowever, process AS will advance the value of EZNIAZ only 
after both A2Z and AS have completed. This allows Al to wait 
for tne two events HOMO CI (il oO mCOM pletion: Of 
processes AZ and AZ) before it begins again. Thus with the 
single Advance operation performed by Al on Z2NTA1 two 
processes begin execution. ; 

This example has shown how the nrogramrmer can 
easily make use of eventcounts to Syuchronize paréllel 
processes with the same methodology used for sequential 
processes. 

c. Mutual Exclusion &Sxample 
Mutual exclusion is required in certain 


Situaticns where one and only one process can te allcwed to 


access a sheared resource (some set of data) ata time. 
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PROGRAM MODULE PRINTER PROCESS: T[0; 
/* Declare eventcounts FULLB and EMPTY, used */ 
/* by all of the processes ay, 
DECLARE FULLB(6) BYTE DATA (’°FULIBY”); 
DFCLARS EMPTY(6) FYTE DATA (’ RMP TTY” )3 


/* Declare a local word variable */ 
DECLARE AGAIN WORD; 


/* Declare synchronization primitives */ 
ve Advance and Await oy 


/* Begin Mainline */ 

/* Create the eventcounts */ 

DO WHILE 1; /* To forever */ 
CALL AWAIT(@FULLE,AGAIN) ; 
/* Perform processing aa, 
[* Processing complete, notify others */ 
/* that tuffer is évailable ae / 
CALL ADVANCE(Q@EMPTY); 


/* Increment the value to await */ 
AGAIN = AGAIN + 1; 


END; /* Of Do Forever */ 


END; /* Of Module */ 


PFINTER PROCESS FOR MUTUAL EXCLUSION FXYAMPLE 
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PROGRAM MODULES Al TFROUGE Ak: DO; 


/* Declare eventcounts FULLB and a sequencer */ 
/* used by all of the processes. Sequencer */ 
/* by all of the processes. Sequencer is / 
CECLARE FULLE(6) RYTE DATA ( "FULLBS ® 3 
DECLARE EMPTY(6) BYTE DATA (’°EMPTY%”); 
DECLARE TURNA(6) BYTE DATA ( DURNAZ’)3 


/* Declare some local variables among which is T */ 
DECLARE T WORD; 


Beeeveciare synchronization primitives aa 

/* Advance and Await as before plus Ticket */ 

TICKET: PROCEDURE(SEQUFNCER) WORD BSXTERNAL; 
DECLARE S*QUENCER POINTER; 

END; 


/* Begin Mainline */ 


e 


/* At this point process needs to print data 
/* $0 create the eventcounts as usual and create * 
/® the sequencer : 
CALL CREATESSEFQ(GTUPNA) 5 


/* Obtain a turn for the buffer */ 
T = TICKET(GTUENA); 


/* Wait for ‘turn to come up * 
CALL AWAIT(GEMFTY,T); 


/* When awakened, process may use the */ 
/* puffer (its “turn” has come up) * 


/* Finished with the buffer so notify */ 
/* Frinter Process that there is output */ 
CALI ADVANCE(@FULLEB); 


END; /* Of Module */ 


PROCESSES Al -— Ak FOR MUTUAL EXCLUSION EXAMPLE 


Figure 25 
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memmencerS ere used in conjunction witn eventcounts to solve 
these types of problems. 

tomes thepe mutual e€@xclusiom, consider the 
flow of control in Figure 23. Here an unxnown number of 
processes (Al throveh Ak) require 4&cceéss to a single 
resource (usei by A3). Printer Process is Some printer 
Semyece and the single shared resource is its input buffer. 
Obviously only one of the processes requesting printer 
services can be allowed to write into the input buffer at a 
time and no process can write into the buffer while Frinter 
Process is trying to transfer the information to the 
printer. 

The solution is shown in figures 24 and 25. 
Figure 24 shows the programming of Printer Frocess and 
Figure 25 shows how each of the processes requiring printer 
Services are programmed. 

In Figure 16, Printer Process only requires tne 
use of eventcounts (since it does not alter the data in the 
input buffer). It only needs to know when to begin 
transferring the data and to signal that the buffer is free 
upon completion of the transfer. Thus Frinter Process only 
mess two eventcounts, FULE and EMPTY corresponding to tne 
buffer’s containing data from a process (FULI) and its teing 
emptied by Printer Process (EMPTY). Thus Frinter Process 
Perrorms Wan “Await operation on FULL and Waite for an input 


process to sive it some data. When a process performs an 





Advance on FULL, Printer Process will be awakened to output 
mieeunem Printer Process finishes outputting the cata, it 
Moe perform an Advance on the eventcount SMFTY ance loop 
Geck to the AwAIT. 

The otner processes, Figure 25, are to use the 
Semeeventcounts, performing Awaits on the eventcounts EMPTY 
(waitine for the buffer to become available) and FUII 
(signalling Printer Process that there is data to print 
out). Fowever, the awaited value is derived from a TICKET 
operation on tne sequencer TURN. Note that each cf these 
processes Wiel  peraomm. TICKER Operations on. thous came 
sequencer (TURN) and so will all receive’ unique awaited 
values (“turns’, as in taking &@ number from 4 ticket macnine 
at a department store, [{13]} for the buffer. These TICKET 
operations will return a unique value for the eRe 
merey time it is called irrespective of which process calls 
TICKET (provided the same seaquencer is used as_ the 
argument). Then the processes simply wait for their “turns’ 
to come un. Since each process will wait for its ‘turn, 
there will only be one process writing into the buffer at a 
time. 

This example demonstrates the use of sequencers 
in mutual exclusion problems. AS can be Seen, the uSe of 
sequencers provides a very simple way to mediate access to 
eiiammted resources, particularly useful when the numter of 


processes involved is not known in advance or may change. 





Pees OPERATING SYSTaM GATE 

Somehow there must exist a linkage between the user 
processes and the operating system to use the functions 
Outlined in the preceeding paraeraphs. This is provided ty 
linking to each user process one operating system mocule 
known aS a GATE. The GATE contains the Putlic declarations 
for the synchrenization procedures which the user may 
mess. The GATZ, then, allows the user to call operéting 
system procedures in exactly the same way that any HEATERNAL 
procedure would be called. The advantage is that only the 
GATE (which is very Small) must be linxed and loaded with 
each user process, not the entire operating system. 
Additionally, durine system generation [16], the Gate is 
located (FL/M terminology for the assignment of absolute 
addresses) in exactly the same place in memorv for all of 
the processes. The result is that the Gate segments loaded 
Moeewith Gach process “will ove overlayec. Thus all of tne 
processes on a single microcomputer will share the same copy 
of the Gate code. This minimizes tne amount of physical 
memory used ty the Gate. 

Figure 26 tabulates the required format for all of the 
Peon wmeroccanre declarations that must Ge included in 
each user module making use of Operating system functions. 
Note that only the functions actually usecéd neec to be 


declared. 





Creating an Eventcount: 


CREATESEVC: PROCEDURE(EVENTCOUNT) EXTSENAT; 
DECLARE EVENTCOUNT POINTER; 
END; 


Creating a Sequencer: 


CREATESS"O: PROCEDURE(SECUENCER) SXTERNAL; 
DECLARS SEQUENCER POINTER; 
END; 


The Advance Operation: 


ADVANCE: PROCEDURE(EVENTCOUNT) EXTERNAL; 
DECLARE EVENTCOUNT FOINTER; 
END; 


The Await Operation: 


AWAIT: PROCELDURE(EVENTCOUNT,VALITE) EXTERNAL; 
DECLARS EVENTCOUNT POINTER, 
VALUE WORD; 
END} 


The Ticket Operation: 
TICKET: PROCEDURE(SEQUENCER) BYTE EXTERNAT; 
DECLARE SEQUENCER POINTER; 
END; 
The Read Operation: 
READ: PROCEDURE(EVENTCOUNT) BYTE EXTERNAL; 


DECLARE EVENTCOUNT FOINTSR2; 
END; 


KERNEL CALL EXTERNAL PROCEDURE DECLARATIONS 


Pigure 26 
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BRB. SHARED PROGRAM CODE 


Frocesses can be made to share code as long as they are 
all loaded on the same microcomputer and the shared modules 
all nave the “REENTRANT” attribute. This places all variable 
storage on the stack so that there is no confusion when two 
processes try to invoxe the module at the same time. 

Because the system is bus-oriented (all of tne 
microcomputers share a single system tus). code sharing 
Should not usually be forced for processes which reside in 


different microcomputers. This r€auirés access to the sy 


in 


tem 
bus for instruction fetches making this tecknique less 
peeeeerent. Therefore, glotal sharing of code is not not tne 
expected convention during system generation, although it is 
not prevented outright [16]. In fact the programmer will not 
be in direct command as the system generation operator will 
make this decision. 

Pmee Tile ot thumb that quite often applies to attempts 
at optimization is that the memory that is saved is paid for 
with a loss of speed. Guite often one can speed execution up 
drastically if he is not overly concernec atout usite 
memory. 

In summary, the sharing of code segments to save memory 
is a technique that is discouraged in this system if the 
processes which share toem reside on different 
microcomputers. It will ‘work’, of course, but has a very 


detrimental effect on performance. 
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feaeak D> TATA 


Sharing of data between processes is tightly-coupled in 
meat tne data is not explicitly transmitted from one process 
memeanother. Father, data sharing is accomplished by using 
shared PL/M data segments. These shared data segments can 
Pesice in globél memory where they are directly accessibie 
to the processes concerned. 

Ee M eo one to develop programs modularly ty 
providing cata declarations with FUELIC and EXTSRNAL 
attributes. Wnen the modvlés are linxed, all of the declared 
variables (such as byte, word and pointer quantities, 
arrays, structures, etc.) are collected into a single data 
Segment for the program. Thus PI/M-€6 expects that each 
program will have its own local data segment. 

In modules where a variatle is declared with the 
EATZRNAL attribute, it is understood that the variable may 
actually reside in a non-local data segment. The intention 
is that eventually, when all of these modules are linked 
together into one program the PUBLIC and EXTERNAL references 
will be resolved. 

Frocesses, though are not linked togetner. Tnev are 
altogether independent PI/M programs. Eowever, one can share 
data in much the same way as the modules in a single fFL/? 
peoecaveeby declaring @11 shared data in the processes with 
the EXTERNAL attribute. Thus eacn process will be aware of 


the existence of a separate data segment. The shared cata 





se=ment is then Separately created as a FI/™ module 


containing only shared data declared with the FPUEFLIC 
attribute -- no local data or code iS ever included. This 
module is then compiled separately and linxed to each of the 
processes Sharing the data as if it were Simply another 
program module. The only difference is that this module will 
only have a meaningful data segment. The code segment will 
be empty. 

It must be emphasized that such data segments are the 
Only means of communication between processes. In 
particular, a reference to an absolute address (including 
constant or computed pointer values) is NiVlk allowed. To do 
so Will cestroy the integrity of this operating system 


design. 


Seer aiVILSGED INSTRUCTIONS 


secause the operating system controls tne physical 
resources of the system, certain instructions which are 
valid in either the hign level language FL/M or the EES 
assemblv language ASM-86 may not te used. The reason for 
this is that their use will interfere with the correct 
pppemetion of the system. 
1. Interrupt Masxine 
iiemopomating system uses the inverrupt structure of 
the system for its own purposes. Because of this, the user 


must never, repeat NEVER, mask interrupts using the assemtly 


eS 





Tlaneuaze CLI/STI instructions or the PLI/M-&6 LISABLE/SNAELE 
mootructions. 

The operating system uses interrupts system-wide 
oirane normal opé€ration and requires that interrupts be 
unmasked at all times while uSer processes are executing. 

‘irs memedot to ve confused with the use of interrupt 
Mandler routines which are required for certain software 
packages, notably the PL/M-86 real number library routines. 
These will not interfere with system operation. 

2. Input/Output Operations 

Dinecveaccess torlnput/Outgpur racilities is @lso 
the purview of the operating System. Thus the user is also 
Beomerited from using the PL/M and ASM-86 I/9 instructions. 
Instead, a SsyStem Service iS provided to overform 1/0 


fometions for the user. 





APPENDIX E - KERNEL MODULES 


This section contains the detail “pseudo-code 
for the kKerrel modules. These have not been 
meee bested and Should only be considered an 
aid to understanding and not final code. 
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; External PL/M-&6 procedures called by this module 
EXTRN GETWORE: FAR, 

MUN Gov es 2 An, 

moron tovr: FAR, 

LOCEVEM. FAR, 

UNLOCKVFM: FAR 


SCHEDULER SEGMENT 
PUELIC VPSCHEDULER 
VFSCHEDULER FROC FAR 
ASSUME CS:SCHEDULER 
ASSUME DS:NOTEING 


ASSUME SS:NOTHING 
ASSUMS& ES:NOTHING 


[elnurky point for a call to YpScheduler 
; Establish activation record, save registers that 
’ YoScheduler will use. 

Even US 

PUSH AX 

FUSH CX 

Pvion LP 


CALL LOCRYPM 
CALL RDYTHISVE 
MOVE? , SP 





~~ @ 


2e “®e¢ We We We wWe 


MOV CX,@H ; @H indicates normal return 


Moye DOlNt es: @nea preempt interrupt. Reached by a jump 


from ITC PREEMPT EANDIGR procedure. 


INT_ENTRY: PUSH CX 


CALL GETWORK ; Returns new DBR 


>» AX register 
POF CX 


in the 


Swap virtual processors. This is accomplished by saving 
the SP and EP registers in known locations at the base 
of the stack along with tne VpScheduler return type 
flag. The process bound to the Selected virtual 
mse eccessidDle vie the acdress space descriptor, 


the SS register value. 


MOVs Soeeonl Raed, S P 
Woy sNORD PLR 2,8P 


MOV SS:WORD PTR 4,CX 5 Return tyne flag 
MOV SS,AX > New address space desc. 


Swap is complete at this point since the 55 
now holds the new stack segment value 


MON@or,oo:"0nD Fin @ 
POW SP,SSHWORD PTR 2 
PUSH AX 

CALL RUNTEHISVP 

MOV CX,SS:WORD PTR 4 


register 


Check Vpscheduler return type flag to determine tne type 


of return required for the process. 
CMP Ci,77F ere turerewey pew. lat 


= Interrupt? 


JNE NOPM RET 5 If not, do a normal return 
IMP INT RET 3; If so, do an interrupt return 


NORM_RET: CALL UNLOCKVPM 
POF BF 
POP CX 
POP AX 


VPSCHSDULER =SNDP 
ITC PREEMPT FANDLER FROC FAR 


ASSUME CS:SCHEDULER 


1¢6 





ASSUME [TS:NOTHING 
ASSUME SS:NOTHING 
ASSUME ES:NOTEING 


INT VEC: CLI 
PUSH ES 
PUSE DS 
PUSE AX 
PUSH CX 
PUSE DX 
PUSH EX 
PUSE SI 
PUSE DI 
CALL LOCKVPM 
CALL RDYTHISVP 
IMP INT ENTRY 
INT RET: CALL UNIOCKVPM 
CALL CEECKPREEMPT 
POP DI 
POP SI 
POP BX 
POP DX 
POP CX 
POP AX 
POP DS 
POP ES 
IRET 


ITC PREEMPT HANDLER ENDF 
SCREDULER ENTS 
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/* Externally DTefined Variable Declarations 


DECLARE VFM(1) STRUCTURE 


(VPSSTATE BYTE, 
VPSPRIORITY EVIG, 
EVCSAWSID BYoE. 
EVCSAYSVALUE WORD, 
SSSREG WORD, 

SPEND BYTE) EXTERNAL; 


DECLARE VPMSLOCK EYTE EXTERNAL; 


« 
- 
e 
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DECLARE(CPUSNUMBER,VPSSTART,VPSEND,VOSSPERSCPU) 
BYTE EXTERNAL; 


DECLARS IDLESDBR WORD SXTERNAL; 
DECLARE CPUSINTSVECTOR(16) BYTE EXTERNAL; 


yee Literal constants 8 / 
DECLARE FALSE LUeR ALLY “Oi 

map’ LITERALLY ci 

PUNNING LITERALLY ae 

WAITING LITERALLY oT 

IDLE GRERALLY « °15°, 

TRUE LITERALLY °119°; 
is External Procedure Declarations ay, 
TCSPESHANDLER: PROCEDURE EXTERNAL} 
BND; 
[RFR AE ERE IS EME TH He ae a Ae Be He 2s ae aa ae SNE oe ae a Ne ae ao Be a aI aK Aa a BESS a SE aI SC a SIE SIE / 
/* GETWORK Procedure s / 
[8a -- -- — -- -  - -— - - -- - + - x / 
/% Function call. Searches the Virtual Processor Map */ 
/* the nighest priority runnable virtual processor a7, 
i (state is either reaPy or idle with the Preempt 7 
Le Pending Flag set). Returns the DBR value (SS a7, 
ye Register value) of the bound process in the Ax 7 
[* Register. o/ 
/ ER eects cee es < snot S10 7c 3.2 50 S12 He Oe Be She Sie Sie Sie sie Sis ole Sie Sie Sic ate ste ste see git Sie She SiS SiS 345 Tie DHS B15 Soe Oye NS Dye Tye Bye 2s Bye 2g8 oe Oye ge Ne V 


GETWORK: PROCEDURE WORD REENTRANT FURLIC; 


DECLARE (PRI,I) BYTE; 
DECLARE SELECTEDSDBR WORD; 


/* Begin search of the Virtual Processor Map using the 
/* priorities. Initially set to the lowest possible. 
PRI = 255; 
DO /* Search Virtual Precessor Map for the highest 
Peeoriarmity ready virtual processor to run. 
I = VPSSTART TO VPSEND; 


Ir /* The virtual processor can be Selected, it is 
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/* is either the ready state, or the idle state 7, 
/* with a virtual preempt pending. / 
((VPM(I).VPSPRIORITY < PRI) AND 
(VFM(I).VPSSTATE = READY OR 
(VPM(I).VPSSTATE = IDLE AND 
VPM(I).PESPEND = TRUE))) THEN 


DO; /* Select the virtual processor. */ 
SELECTEDSDBR = VEM(I).SSSREG;3 
PRI = VFM(I).VPSPRIORITY; 

END; /* Do. Select the virtual processor. */ 


END; /* DO loop search of the Virtual Processor Map. */ 

/* Return the SSSREG value of the selected virtual a / 
/* processor in the AX (Accumulator) Register. 

RETURN SELECTEDSTIBR; 


BND; /* GETWORK Procedure. */ 


[Me REAE HEHE ARTE HEH HRI HE EI HHH SET a HB ae aa a AE a a aa ae ae a a afc ae ae aa ae ao fe aah ae ae ae ae ak ee / 
ye RUNTHISVP Frocedure oo 
ee ee ee oe ae ee a oe oe oe ae ee ee ee xe / 
[> Sets the selected virtual processor to running. 7, 
AS Searches the Virtual Processor Map with the oy, 
* process S SELECTEDSIBR. ny. 
[Be ea He He He He ae aie seats ie aes ae a ae a ae ae he He oe ae aise ae afc ae ae ae afc fe ai ah ae abe a ae ae fs ae ak aia 2s ale alcaig ate ae aie atte ae ake 
RUNTEISVP: PROCEDURE(VESDER) REENTRANT PUBLIC; 
DECLARE VPSDBR wORD, 
VP BYTL; 
VF = VPSEND; 
DC WRILE /* Look for the VP with this SSSREG valve. */ 
(VPM(VEF).SS$RiG <> VPSDBR); 
VP = VP —- 1; 

END; /* Do While */ 

VEM(VP).VESSTATS = RUNNING; 

RETURN; 
END; /* RUNTHISVP Procedure. */ 
J PRARHE AE AE HB BE BBE AEE BE AEE BS HE HIS BS BS HS SAE AS RAC HS FSIS SME AES EIS AE FC AIS BE HS TIS AC AE HE OE SIE SISA AE TIE FAS AAS IE IE / 
Hes RDYTEISVF Frocedure 7 
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VPM(ITCSRETSVP).VPSSTATE = READY} 
/* RDYTHISVP Procedure */ 


RETURN; 
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PROCEDURE REENTRANT PUBLIC; 
ILE LOCKSET(@VPM 


T? 
Ci 


y 
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END; 
/* LOCKVPM Frocedure. */ 


LOCKVFM: 
Peo eo built 
DO \ 
RETURN; 

SND; 
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PUBLIC; 


REENTRANT 


ELURE 


PROC 


UNLOCKV PM 


VPMSLOCK = 2 
RETURN; 


Je 
=e / 
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END; 
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PORTA LITERALLY “¢C&H’: 
OUTPUT(PORTA) = CPUSINTSVECTOR (CPU); 


RETURN 
END; /* EDWFSINT Procedure. */ 


[FR PR IE RERE TR TEE BE BENS HE SEES HE NS CT HI HE NE We ce sae ma ste 3 HS F aeicie oe oe cece fae bp 3K isis oy 218 3.8 Suk cae cat eee oie can ee ak 2 peace eae s: 
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/* Inner fraeric Controller ere DOG es ser 
Sense oe ef Bae S Bien ewe miapeioye aye oye mses ee eee Sas aren eee os < ote ste me aees o. jap oseue 2x ae .on <see 7. ity pcs ccit es oe / 


[BEAMS AED AR AE MEDS SRE SARI MES He ET BE A Be ae ah aha cake OR Ae Ea fe oR ae a a as a Ne ae ae ake aka ak ak a a ae ahaa oie / 
/* IDLESTE Procedure  / 
[Bh enn nn nnn nn nn ee a / 
ie Sets the state of the virtual processor now oy 
/* running to idle, binds the Idle DBR, sets a a7, 
/* high priority and calls Vo Scheduler. ar, 
[BRIA ETE NE a Mea Be BE Re a a ae ae Ae a ake Beate a oa Be SE ae a ae ae of ag ae ae ae ak ae ae ae ae ae ae Bae aa ae ake / 
IDLESVP: FROCEDURE REENTRANT PUBLIC} 
DECLARE VPSTOSIDLE BYTE; 

VPSTOSIDLE = ITCSRETSVP; 

VPM(VPSTOSIILE).VPSSTATE = IDLE; 

VPM(VPSTOSIDLE).VPSPRIORITY = 123 

VPM(VPSTOSIDLE).SSSREG = IDLESDER; 

CALL VOSCEEDULER; 

RETURN 5 
END; /* IDLESVP Frocedure. */ 
[PERE eve coe se see aly Jd sp Saree ase, 4 sane anos ceo. Sraasese Bie tee fee ee crn ac - a. sais eve cpanel a ae oe se Se Soes Somes se 22. eeitie sie ae / 
* eECoADSTP. Procedure o/, 
asco. = = ~~~ = --- Ss laeieniliiaaianintaaanian an ance iain aes ae au /) 
eg Performs a Swap Virtual DER . Binds the virtual */ 
Vee processor to the new process, updates VPSPRIORITY */ 
T and oe ae sets uae to ready. x / 
[eRe IE meee eee cis cic ace eee a eae oie kee o.e Shere oe ee ae eimai cients e Oc Sicleje date. < 9,0 2,0 2,0 24k Sas 2k 9,8 ne Oct oye Me Bye See og? See / 


ITCSLOADSVP: PROCEIURE(PRISPARM,DERSPARM) REENTRANT PUELIC; 


DECLARE PRISPARM BYTE, 
DBRSPARM WORD, 
LOATSVP RTE: 





ye identify runnine virtual processor. */ 
LOADSVP = ITCSRETSYVP} 


/* Bind the virtual processor. */ 
VPM(LOADSVP).VPSSTAT®S = READY; 
VPM(LOADSVP). Surat = PRISPARM; 
VPM(LOADSVP).SSSREG = DERSPARM; 


/* Schedule the virtual processor. */ 
CALL VPSCREDULER; 


RETURN; 
END; /* ITCSLOADSVP Procedure. */ 


[MMH Hee RAS He a Se He eae ae a a ae ae aa ae ae ea ae ae te ah eke ae ae see ee a a ae ale aeate he Se ae a ae aie a / 
/* ITCSRETSVP Procedure = / 
> Pm@etion call which returns the identity of the * / 
Lae virtual processor which is now running on the ae / 
* physical processor. Ha 
Ieee ee 2 ee acc ye tre cs Ds Hoe se ea ee ee ee ahe Mee oe oe eae Ae He OK ae aaa ae Se ae eae ae oe ea ea ek / 


ITCSRETST7P: PROCEDURE BYTE REENTRANT FUELIC; 


/* Search through the set of virtual processors assigned */ 
/* to the phsyical processor. 7 
RUNNINGSVPSID = VPSSTART; 


DO WHILE /* Fave not found the running virtual processor */ 
(VPM(PUNNINGSVPSII).VESSTATE <> RUNNING); 


/* Search next entry. */ 
RUNNINGSVPSID = Be ancsvaiis tale 


END; /* While loop search for running VP. RUNNINGSVPSIT * 
/* poimts to the running virtual processor. se 


~~ 


/* Return the identity of the virtual processor By 
/* in the AX (Accumulator) Register x / 
RETURN RUNNINGSVPSID; 


END; /* ITCSRETSVE Procedure. */ 


[FER ER EE te ste see she ote seals ae 24s HS EME SE Be HS IS De NES IE NE PS HE AS TS OS BS TIS HS ETE He TE HE NE DIS NE I ME TENE DIS OE NE ME AC AE SE 3s SHS / 
[* CFECKPREEMPT Procedure x / 
[enn nr a / 





le Checks for a virtual preempt pending. If there 
jee is one, calls the Traffic Controller Preempt 
ec Fandler. 
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CRECKPRESMPT: PROCEDURE REENTRANT PUBLIC; ‘ 
DECLARE RUNNINGSVP BYTE; 


/* Find the identity of the running virtual processor 
RUNNINGSV? = ITCSRETSVP; 


DO WEILE /* Preempt Fending Flag of the virtual */ 
/* processor iS on. 7), 
VPM(RUNNINGSVP).PESPEND = TRUE; 


/* Reset Freempt Pending Flag. */ 
VPM(RUNNINGSVP).PESPEND = FALSS; 


/* and call Traffic Controller Preempt Eandler. ° 


CALL TCSPESFANDLER; 
RUNNINGSVP = ITCSRET$VP; 


a, 
28 / 
* / 
a / 


fee /* while loop handling of the virtual oreempt. apy 
RETURN; 
END; /* CHECKPREEMPT Procedure. */ 
7 Bye aie vas 2e% oes 2ye roslege ayo Soe Pas Sys Sgk eis Mam Mae Uye AAe Bee ye See aye Ug TS Bee Byh es PE DES BES DES BAS Bye SE TE B4S HS BES BS BS Bh SES Sys NS LS NTT Se SIS BS Te Be Sys Me / 
ye i ety p nea aacne a7 
[3 errno / 
/* Issues virtual preempts (preempt interrupts to of 
Se weeentidl processors) by setting the appropriate a 
Ves Freempt Pending Flag in the Virtual Processor Map */ 
Van and then isSuing a hardware interrupt if the / 
3 Dice or is on a lew eee! processor. a 
/ 38 3% 8 38 ed 45 38 *e 38 3s 38 3% 8 38 a3 3 $38 8 3 xe ae 3 35 3348 ae 25 35 28 vs 


ITCSSENDSPREEMPT: PROCEDURE(TGTSCFU,VPSID) REENTRANT FPUELIC; 


DECLARE TGTSCPJ WORD, 
VFSID WORDS 


/* SEPT THE FPRE-EMPT PENDING FLAG */ 
VEM(TGTSCPU * VPSSPERSCPU + VPSID).PESPEND = TRUS; 
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IF (TGTSCPY <> CPUSNUMBER) THEN 
Alu HDWaRS INT (TGTSCPU); 


RETURN; 

BND; /* ITCSSSNDSPREEMPT Procedure. */ 

[PERE AR ERE AEH BE HERE RE AONE BE a RET Be HE EE TE RE eS I he EO IS aS ae He a 2 aE fe ye ae a a ate ote cake a fe ae alee ae ale / 
/* ITCSAWAIT Procedure x / 
/* SS ee ee ee ee a a en a es a we me a a a a ee ee  / 
a Eventcount synchronization mechanism for use by the */ 
ye Inner Traffic Controller in the management of ay, 
y= system resources. x / 
[PEPE RR BETS AS BE HEHE AEBS AE EAE AE FS AE BENE HE BE AE BE AE OS AE OE SESS EAE SIS FH ENE IE SAE AAS AE DE AE AC AS EE OE DIE AE AS EE IR IS BE ESTEE / 


ITCSAWAIT: PROCEDURE(EVCSID,AWAITEDSVALUE) REENTRANT PUELIC; 
DECLARE EVCSID Bonn 
AWAITEDSYALUE WORD, 
RUNNINGSVP BYTE, 
iy BYTE; 


/* Lock the Virtual Frocessor Map */ 
DO WHILE LOCKSET(@VPMSLOCK ,119)3 
END; 


DO; 
/* Identify the running virtual processor */ 
RUNNINGSVP = ITCSRETSVF; 


IF SYSSETCSTABLE(EVCSID) < AWAITEDSVALUE THEN 


DO; 
VPM(RUNNINGSVP).VPSSTATS = WAITING; 
VPM(RUNNINGSVP) .EVCSAWSID = SVCSID; 
VPM(RUNNINGSVP) .EVCSAWSVALUZ = AVAITEDSVALUE; 
END} 


ELSE 


VEM(RUNNINGSVP).VPSSTATE = READY; 
ND; 


bey 


/* Schedule the virtual processor. */ 
CALL VESCHEDULER 5 


/* Wnlock the Virtual Processor Map. */ 
VPMSLOCK = @; 
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. 


RETURN; 
END; /* ITCSAWAIT Procedure. */ 


eb i a ae 6? Se 4 OS Gr Fe Gr PPe 2,0 Ogr Oye AR Ope Fe Oe HY 4, o- 7 oy a" 


yes ITCSADVANCE Procedure st 


4 
ee terest ee ate te eee eng Sects oka mnie Ss nine Dee oe se ate Shesic 2h ake Slee hea skeah ok Vcaeeaie ae keate Nestea ate steak a / 


is Eventcount signalling mechanism. Used by the Inner */ 
/* Traffic Controller in managing resources. ve 
[FREE AE HE HE HE HE HE HE HE NE EAE AE ASHE I IS 2 BS 2S BS Bye AE HAL AE NE AE OE SIE AS I TE SS NS TS BE SES TE IS IS HSS SE TC SS ESI STS / 


ITCSADVANCE: PROCEDURE(EVCSID) REENTRANT PUELIC 
DECLARE EVCSID BYTE, 
I BYTE; 


/* Lock the Virtual Processor Map */ 
DO WHILE LOCKSET(G@VPMSLOCK,119); 
END; 


SYSSEVCSTABLE(EVCSID) = SYSSEVCSTABLE(EVCSID) + 13 


DO I = @ TO (NRSVPS - 1)3 
IF VPM(I).EVCSAWSID = EVCSID THEN 
IF VPM(I).EVCSAWSVALUE <= SYSSEVCSTAELE{EVCSIL) TREN 
DO; 
VPM(I).VPSSTATE = REALY; 
Or cla = 255; 
VPM(I).EBVCSAWSVALUE = @;3 
IF (I < VESSTART) OR (I > VESEND) THEN 
CALL ELWRSINT(I/VPSSPERSCEU); 
END; 
PND; 
CALL VPSCFEDULER; 


/* Urlock the Virtual Processor Map */ 
VEMSLOCK = Q3 


RETURN; 
END; /* ITCSADVANCE Procedure. */ 


[i Pare cee ee eae whe Ja ale stese ate als whe ale ale ale ale ale We We ale So ste ste se whe ale Sa aly ats ale ale vere wile ate abe ale ate ate ale ale ale aly ale ale ale ale ate sto Soe We ale ate ale 

aye HP AD AS 99s ge Hye Oye Oye 24s Sys oR Oye Se oye OLD Spe Oye Ye FES AED SYD AED SFO AS SR Ss YR SAN SEs BS YS Sys SFe AS AR GS OAS 24s AROS SEs AS AP gs AS Mee Ae AS HP GS Had Ha? E™ ADE UP A HE vs 

f= RAFFIC CONTZOLLER 7 
ie an aie } md 

i = 


. 
mM 
4 
We ale als als We Jo ste Sa ve eo wheats we ale ale oleate ale ale ale slo ule ale ale we So cla ale ale Ve ale als ale ale ale ale aly ale ate als ale 3‘¢ ale ale ade ale ale te ale ate ale alte ale ate ate Sento ¢ 
- PEE PES AS gh gs Is gs ofa YE AS CARAS AS GR SGe SYe A 24d 24S OUR Or OY AAS O GR 4% AYO Ge Oye AS OY FES YS SYR CEe OTe MEE HES DE O49 gd Oye Fee 4% OE> AA AY EN ES TEP E> ME MEP DE Ue AE ADP US f 


ae we ale ate ale ale ate ala ate ateate ate ateate ale ale slo slo ale ale ats ate ate ate aleates ate aloate ale ale ate ale alteate a's aboate ale ate ateats abo ate ale ate als ale ate ate ate ate ats sla ate ate ate ate ale 
GyP Oye SS SG> gd 2d PGP OG SEN OAS HGS AER FyDGyd qe O49 Oge Oye Sym Sym Ayr O4s PGS SgR O4d OGD Shr PgR Qe Sym O4> qe ye SAT Ee Oye FAS MA Oye Lr gh Ee SAS Og> Od Gye HD M{e Fy> PA Oye Hye GAs Oy yr Hye O Lr Ad Oy 


EG Panett naiememmobal Sata TLeclarations  / 


le “ we als ale Se ye ate Se alee la Sods ala Se ale Se ate Jo ale ve we s's aleste whe ale ale ate ale als aly abe Sa le alone ate Se ale ge ats we ate ale ale ate Joste ale So ate ale ale ate ate ateate § + 
gh FED gd Gye Myh Put Sgr Sar ye See FEh My> Sgr Mgt ye yr Sg™ Syw~ AM Gye Fgh Cyr CyW gr MyDS ee Cy Gyr GAD Hye Hye SEM Hye MyM Hym OLN yD Gyr YW PEW Oyr Oy ym % Cd tela tolled eld Wd ed bale tld told bit nel tallied tedlied tliat balled be 


ae 
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DECLARE APT(i) STRUCTURE 

(STATE Bs 

AFFINITY BYTE, 

VPSIT Bere. 

PRIORITY BYTE, 

LOADSTHREAD BYTE. 

EVCSVALUESAW WORD, 

THREAD Bers, 

DER WORD) EXTERNAL} 
DECLARE APTSLOCK BYTE SXTERNAL} 
DECLARE PROCESSES BYTE EXTERNAL; 
DECLARE LOATSLIST(16) BYTE EXTERNAL; 
DECLARE EVCSTABLE(1) STRUCTURE 

(EVCSNAMZ (6) orrs, 

EVCSVALUE WORD, 

APTSPTR BYTE) EXTERNAL; 
DECLARE EVENTS BYTE EXTERNAT; 
DECLARE pemeege: 2) STRUCTURE 

(SEGSNAME(6) BYTE, 

SEOSVALUE WORD) EXTERNAL} 
DECLARE SECGUENCERS BYTE EXTERNAL} 
DECLARE (CPUSNUMEER,VPSSTART ,VPSENC,VPSSPERSCPI) 

BYTE EXTERNAL; 

DECLARE (NRSPEPS,NRASVPS) BYTE EXTERNAL; 
DECLARES CPUSINTSVECTOR(16) BYTE EXTERNAL; 
DECLARE PROSPARAM STRUCTURE 

CPIPNG S WORD, 

cS WORD, 

IP WORD, 

ES WORD, 

DS WORD, 

AY wORT 9 

Cx WORD, 

ine WORD, 

EX WORT, 

SI WORD, a 

mT WORD, 


LEG 





Ss WORD, 
ene nee Es, 
See tay RYTE) EXTERNAL; 


[* Prrertal Constant Declarations /- 
DECLARE FALSE LITERALLY ca 

READY LITERALLY elaces 

RUNNING LITERALLY a3 2 

BLOCKED LITERALLY aa 

TRUE DIiTheAbE, 119°, 

NOTSFOUND LITERALLY °255’, 

NIL LITERALLY °2557°;3 
ve pHxternal Frocedure Declarations es 
ITCSRET$VP: PROCEDURE BYTE EXTERNAL} 


END; 


ITCSLOALSVP: PROCEDUFE(PRISPARM,LTERSPARM) FXTERNAL3 
DECLARE PRISPARM BYTE, 
DERSFARM VORD} 
END; 


IDLESVP: PROCEDURE FXTERNAL; 
END; 


ITCSSENDSPREEMPT: PROCELUEE(TGTSCFU,VPSID) EXTERNAL; 
DECLARE TGTSCPU WORL, 
VESID WORD: 


END; 

7 f cs, = at pa, oe > 4 s< cece aoe si ssc ac ss sc Se et ed 
- THE PROCESS SiG ey eee a7 
[ie BS HS AES HS SOE SIS 24 a SS AS BI IIE NS HS BES FS OIE IIS HE IE 2 24S BE HE BE AE HS BE SHE ASS 28 SIE TS IE AS BE AE NE OIE AS IE TE OS ES SIS / 
SE aie Bie Oge SEMIS Ne Bue Sgs 21S Pas Sek qe One B BEDE AE SE AE AK AE HE HE BR BE AE OES BES AE AE AE A Be SEE BE hs 2 Be BENE Oe OS EE BENE TE CC ENE OE / 
Lie TCSSCEEDULER Frocedure 2 / 
[38 er an a ne rn rn ee ae / 
= Process Scheduler. Searches for the highest 7 
Tx priority runnable process to load onto the "/ 
ee imei processor. if no rubmable orocess is 7 
Vac POM» eo a . es PRO OT + = / 
fs 24S BES BIS HHS NIE IS NS 2K I BAS SES By BESS BS BS NHS DYE BYE SS ES HS 348 DiS MS TAS NCTE AS SS EIS SSS Be HE SS ME SS SIS She oe oie ONE oe ats ste ais atk / 


TCSSCEEDULER: PROCELURE REENTRANT PUELIC; 


Law 





DECLARS PROCESS Sela, 
SELECTSPROCESS EYTE; 


PROCESS = LOADSLIST(CPUSNUMBER); 

SELECTSPROCESS = FALSE; 

/* Search down LoadSList for tne highest priority 

/* ready process runnable on this physical processor. 


DO WHILs /* Have not found a runnable process. 
(SELECTSPROCESS = FALSE); 


& ae 
x st rainy 


So 


IF /* Faven’t reached the end of the Load$List */ 
(PROCESS <> NIL) TEEN ; 


DO; /* Check process. */ 


IF /* Process is ready. */ 
(APT(PROCESS).STATE = READY) TEEN 


Ve Select WICwprOocess. FO Dune «/ 
SELECTSrROCSSS = TRUE, 


ELSE 


/* Check the next process. */ 
PROCESS = APT(PROCESS).LOADSTEREAL; 


END; /* If then else. */ . 
END; /* While loop search for next ready process. */ 


IF /* Have found a ready process to run. */ 
(SELECTSPROCESS = TRUE) THEN 


DO; /* Give away the virtual processor. */ 
APT(PROCESS).STATE = RUNNING; 
APT(PROCESS).VPSID = ITCSRETSVP; 
CALI ITCSLOADSVFE(APT( PROCESS) .PRIORITY,APT(PROCESS) .DER); 
END; /* Give away the virtual processor. * 


BISE 
/* No runnable process has been found so idle the ay 
Paeviriuel processor. x / 


CALL IDLESVP; 


RETURN; 


ae 





END; /* TCSSCHEDULER Procedure.*/ 


RRA RTE AS AE A ORK He AE He a GR HR ft a aa AIH Sea IE CH REE ACD ME aE Cea aa ae Ie af ae a a a ak ak aa / 
I PROCESS SCEEDULER INTERNAL MODULES a7 
[BERT A HR He ee RH a he ee ea ea ae Be Ne ok ae he Se ae fk a aa 2h Aa He tt eae 2k ea aie eat fee ke Ne ak ke ae ae ae / 
[FERRIS HE BE IE HK ASAE BRAS HS EAT HE HE HE ENE HE AC FE I FE ; EATS Ae ois  / 
= TCSLOCATESEVC Beenie. i / 
[i ww enn a an a a ze / 
ye Function call. Returns the identity of the 7, 
8 eventcount (the index of the eventcount in the af 
i Eventcount Table) in the AX (Accumuldtor) 7, 
is Resister. Input argument is a pointer to the oy, 
/* byte array in the user process holding the name oh 
of the eventcount. = / 
[FERRE A AH Ae se A a a eae eae ah aco a ae a ae a eae ac oe ae ae ae aca ae ac ab ae SEE eae a SEMAN REE / 


TCSLOCATESEVC: PROCEDURE(ESNAMESPTR) EYTE REENTRANT PUELIC; 


DECLARE ESNAMESPTR FOINTER; 
DECLARE CHAR BASED ESNAMESPTR (5) RYTE; 
DECLARE I BYTE, 
EVCSID BYTE, 
MATCH BYTE; 


eS 1 
EVCSID = @; 
MATCH = FALSB; 


/* Search down the eventcount table to locate the */ 
Pp aestread event count by matching the names By 


DO WEILE /* haven’t found the eventcount ane */ 
/* haven’t reached end of table x / 
(MATCH = FALSE) AND (EVCSID < EVENTS ) 


IF /* the two characters match */ 
(CRAR(I) = EVCSTABLE(EVCSID) .EVCSNAME(I)) TEN 


DO; /* Check for end of strings */ 


IF /* Reached the end of the strings */ 
CHAR(I) = “%° THEN 


/* Fave located the desired eventcount */ 
MATCH = TRUE; 


1.49 





EISE 


Zoecoommay time next character */ 
P= tir 1; 


END; /* Check for end of strings */ 
ELSE 
DO; /* Ready for check next entry */ 


I = @; 
EVCSID = EVC$ID + 1; 


END; /* Ready for check next entry */ 
Mis /* While loop search for desired eventcount */ 


IF /* Have found the eventcount */ 
(MATCE = TRUE) THEN 


Pewee turn its index in the SYCSTABLE */ 
RETURN EVCSID; 


ELSE 


/* Return NOTSFOUND error code */ 
RETURN NOTS FOUND; 


END; /* TCSLOCATESEVC Procedure. */ 


[RARER HE HAE HET He ENE Se he eae Se ae a ahs Be ac ae oe aes ah le fe he Nea ae eRe ah ae aye ae afc ae ate ae ae ke alee a as ae ae Re ake Ne / 
Be TCSLOCATSSSEG Frocedure a8 / 
[| ¥ enn nnn nn nn nn nn x / 
/% Fomenon Ccdll. Returns the index in the a7, 
ie sequencer table of the sequencer name given a7 
ie oro t edreudment is @ pointer to the e/ 
Ls string name of the sequencer in the application a 
vs rogram. / 
[SH Ae Hee TA etc sh Bee Be Se ACHR SE He BASH Me TI IR HAI HI Het ete eee etek / 


TCSLOCATESSEC: PROCEDURE(SSNAMESPTR) BYTE REENTRANT FUBLIC; 


DECLARE S$NAMESPTR POINTE 

DECLARS CHAR BASED SSNAME 

DECLARE I BYTE, 
SEQSID BYTE, 
MATCH BYTE; 


mies 
ers (5) 2YTa; 
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I = ¢; 
SEQSID = @; 
Peer Ge = FAISE; 


/* Search down the sequencer table to locate the */ 
/* desired sequencer by matching the names. st / 


DO WHILE /* Raven’t found the sequencer and */ 
Po java, ehinausted tae 11st. “ / 
(MATCH = FALSE) AND (SEOSID < SECUENCERS); 


je 7* The two Cnraracters match. */ 
(CHAR(I) = SECSTABLE(SEQSID).SECSNAME(I)) THEN 


Dorm Gheck for End of strings. */ ; 


IF /* Reached the end of the Strings. */ 
CHAR(I) = “A° THEN 


/* Have located the desired sequencer. */ 
MATCE = TRUE; 


ELSE 


/* look at the next character. */ 
bo= bt 4; 


mvs) /~ Check tor end of sStrines. */ 
BISE 
DO; /* Ready for check of next entry. */ 


12; 
SECSID = SEQSID + 1; 


END; /* Ready for check of next entry. */ 
END; /* While loop search for desired sequencer. */ 


IF /* Rave found the sequencer. */ 
(MATCH = TRUE) THEN 


/* Return its index in the SEQSTAELE. */ 
RETURN SEC3ID; 


ELSE 


Wan 





/* Return NOTSFOUND error code. */ 
RETURN NOTSFOUND; 


END; /* TCSLOCATESSEC Procedure. */ 


[FRA REI HE AEM IE EH Be He ae ee ee a a a a A kee a a ae a ACH ee eS ae aaa eat ae a ae ae aa ae / 
/* IRAFPIC CONTROLLER INTERFACZ MODULES */ 
[PRR FR ENE EAE TRE BE Din yah crepaiaieicia. B75 Ops Sue Spe TiS Ae ae Som Sie euk tak de tre SIS nie tee tae cae ee tee gs areal, a 
[Fe A ee He He ese ae eRe ae ee ae ae ake he a ae ae ae ae oh aoe aga ac ahs ak ae ae ae ae ae ate ae a eae Seas af eke att ae ate ae ake aie ak ae_/ 
[* AWAIT Procedure a7 
eee ee = 
[ Inter-—process synchronization primitive. ao, 
yes Suspends execution of tne calling precess until a7, 
a - event specified in the input argument ay 
fe EVCSVALSPARM’ has occurred (the eveéntcount  / 
a reaches this value). The result is that the a 
ae process will give away the virtual processor Oh 
yo to which it is bound. 7 
[REAR HEI A AR ae Hee He ae a ae ae Behe ahs eae ae ace a ae ae ae aba kc oR Ne ah ca a a afc ae ae ie beat a fe ae a ae a eae / 
AWAIT: PROCEDURS(EVENTCOUNT VALUE) REENTRANT PUBLIC; 
DECLARES EVENTCOUNT FOINTSR, 

VAIUE YOrT, 

EVCSID BY Ps. 

CUFRENTSVP Een 

PROCESS EYTE; 
/* Assert global lock on the Active Process Table. */ 
DO WHILE LOCKSET(GAPTSLOCK,119); 
END; 
f/m Get identity of the virtual processor running on ao 
/* physical processor.  / 
CURRENTSVP = ITCSRETSVE; 
/* Search the Active Process Table (by the Ioad List ne, 
/* to find the process bound to the running virtual Sf 
/* processor. g7 6 


PROCESS = LOADSLIST(CPUSNUMBER); 


DO WHILE /* Haven’t found the process tound to this vp. */ 
(APT(PROCESS).VPSID <> C'URRENTSVP); 


/* Took at the next entry in the LoadSList. */ 
PROCESS = APT(PROCESS) .LOADSTEREAD; 








mut; /~ While loop Search of LoadSList. */ 


/* Get the EVCSTABLE index for this eventcount. */ 
BYCSID = Deo neCn nen CC SVENTCOUNT);$ 


IF /* This process is to enter the blocked state. */ 
EVCSTAELS(EVCSID).EVCSVALUE < VALUE TEEN 


DO; /* Set the required APT values. */ 


APT(PROCESS).STATE ELOCKED; 
APT(PROCESS).VPSID = NIT} 
AFT (PROCESS ) .EVCSVALUESAW = VALUE; 


/* Add blocked process to head of blocked list. */ 
APT(PEOCESS).TEREAD = 2®VCSTAELE(EVCSID).APTSETR;} 


fameresel a tabae pointer to the current process. */ 
EVCSTABLE(EVCSID).APTSPTR = CURRENTSVP; 


Mnbs /~ To. Place yrocess in the tlocked state. */ 


ELS& 


/~ Tf the event has already occurred, process will */ 


/* enter the ready state -- it will not te blocked. */ 
APT(PEOCESS).STATF = READY; 
APT(PROCESS).VPSID = NIL; 


SLL TCSSCESLDULEE: 


Pomombock 2lobal Active Process Table Locx. */ 
MeTSLOCK = ¢; 


RETURN; 

END; /* AWAIT Procedure. */ 

[PEPE RAE AE BE BE AE BE BEE BS NEE HS AE HS HE BG HE BS HE HE AE OG HE BE NEI BEE SAE ES HE TS HE ETE NS ES IS TE AE ST BIE NS SE AE 2 ZS / 
/* ADVANCE Procedure * / 
[%a-—---------- -— - - +--+ - 5 + - 5 +--+ + -- - -  --* / 
i Used to signal the occurrence of a specified sy 
f* event. Increments the current value of the a7 
fe eventcount. Also signals 41ll processes which oy, 
Ee are in the blocked state waiting for this Event. ss 
[REMIT REAE H IE A TEE HEE NC HEE A RE ea ee a a SS Re See a ae ai aR a a ae we ete eae a ae ae ate ate ak ae / 
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ADVANCS: PROCEDURE(EVENTCOUNT) REENTRANT PUELIC; 
DECLARE EVFNTCOUNT POINTER, 


EVCSID BYE, 
PROCESS Bure. 
PREV BYTE, 
PEP Bers 
VP BYTE, 
HISPRI RYTE, 
PESTOSSEND Bye. 
PESSENT Ess 


DECLARE PESPHP(16) BYTE, 
PESVP(4) pues 


7= Assert global lock on the Active Process Table. */ 
DO WEILE LOCKSET(GAPTSLOCK ,119); 
END; 


/* Increment the value of the eventcount by one. */ 
EVCSTABLE(EVCSID).EVCSVALUE = 
EVCSTABLE(EVCSID).EVCSVALUE + 13 


/* Search Elocked List associated with the eventcount */ 
as ste J 


/* and unblock those processes waiting for this 
/* event. Set PROCESS to the first member of the ef, 
/* Blocked List. x / 


PROCESS = EVCSTABLE(EVCS5ID).AFTSPTR} 
PREV = PROCESS; 


/* Initialize PESPHF array. */ 

DO PHP = @ TO NRSFFPS; 
PESPHP(PHP) = FALSF; 

END; 


DO WHILE /* Not end of Blocked List. */ 
PROCESS <> NIL; 


IF /* The event has already occured. */ 

(EVCSTABLE(EVCSIT) .EVCSVALUE >= 

APT (PROCESS) .EVCSVALUZSSAW) THEN 

DO; /* Unblock process (Set State to ready), zero 7 
/* Eventcount Value Awaited entrv of AFT and a / 
/* flag the physical processor for preemption. */ 
APT(PROCESS).STATE = READY; 
APT(PROCESS).EVCSVALUBSAW = 2; 
PESPEP(AFT(PROCESS). AFFINITY) = TRUE; 
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/* Kemove process from the Blocked List. */ 

[ii meirstemremoer of tne Blocked List. */ 
(PREV = NIL) THEN 
/* Reset pointer around the deleted member. */ 
BVGSTASRE aYCSID).APTSETR = 
APT (PROCESS) .THREAD; 

WLSE 


/* Set previous member’s pointer around the * 


a. 


/ 
/* deleted process. a / 
APT (PREV).TEREAD = APT(PROCESS).TEREAT; 


END; /* Do. Remove process from Blocked List. */ 
/* SEARCH NEXT ENTRY */ 
PREY = PROCESS; 
FROCESS = APT(PROCESS) .TEREAD; 
END; /* While loop search of Blocked List. */ 


DO /* Look for the PEP’s with VP’s to vreempt. */ 
PEP = @ TO PFPS; 


IF /* FFP is flagged for a preempt. */ 
DESPRP(PHP) = TRUE TREN 


LO; /* Find VP“s to preempt. */ 


DO /* Flag all VP’s for preemption. */ 
VP = @ TO VPSSFERSCPU; 


PESVP(VP) = TRUE; 


END; /* Imitialize PESVP array. */ 


ae C; 
PESTOSSEND = @; 
FROCESS = LOADSLIST(FHP); 


DPOVWHIiEM7emceerch down Loed List to find those */ 
/* processes which should be running. a, 
/*® Tetermine which VFs not to preempt. *, 
(PROCESS <> NII) AND 
(HISPRI < VPS$FERSCFU); 





IF /* Found a process which should te running a 
Vumviteactually is running. 
APT(PROCESS).STATE = RUNNING TEEN 


DO; /* Increment number found and do not */ 
/* preempt its VP. o 


HISPRI = HISPRI + 13 
FESVD(AFT(FROCESS).VESID) = FALSE; 
END; 
ris 6 


IF /* Found a process which should te running */ 
/* dbut is in the ready state. x 
APT(PROCESS).STATE = READY THEN 


DO; /* Increment number found and indicate 
/* that a preempt will have to be sent 
Paevomeet it running. 


oN oN 


%. & M« 
st 3° 7. 


FISPRI = HISFERI + 13 
PESTOSSEND = PESTOSSEND + 13 


END; 
END; /* While loop search of Load List. */ 
PESSENT = 03 /* Used to keep track of the */ 
/* rurber of preempts sent. */ 


VP = @; /* Begin at first VP on the PEP. */ 


DO WEILS /* There are more preempts to send. */ 
(PESSENT <= PESTOSSEND); 


Ir /* A preempt is to be sent to this VP. */ 
PESVP(VE) = TRUE TEEN 


DO; /* Issue the preempt and tally it. */ 


CALL ag sce tah el Veal 
PESSENT = PESSENT + 13 


END; /* Issue preempt. */ 


J/* Check the next FP. */ 
VP = VP +1; 





Pita wore loop send preempts. */ 


END; /* While loop determine VPs to preempt. */ 


END; /* Determine PHPs to preempt. */ 


END; 
/* Peady the calling process. 


/* Get identity of running VP. 
tee= ITCSRETSVP; 


ale / 
#* 


/* Search Load List Thread to find VPSID match. */ 


PROCESS = LOADSLIST(CPUSNUMBER );} 


DO WHILE /* Have not found process bound to this VP. */ 


(APT(PROCESS).VPSID <> VP); 


/* Loox at next ertry in boad List. */ 
PROCESS = APT(PROCESS) .LOADSTEREFAD; 


END; /* While loop search of Load List. */ 


/* Ready the calling process. */ 


Bere) cost = READY; 
APT(PROCESS).VPSID = NIL; 


CALL TCSSCFEDULER; 


/* Unlock Active Process Table. */ 

Memo LOCK = CZ; 

RETURN; 

END; /* ADVANCE Procedure. */ 

[MERRIE HE HET He A He He Se He eae ae ae ea Se eas i ae a ae ah fe a ae Ie ale ae eee a see ai ae he afta se Ne ake Se aie ake / 
[* PICK et oo. ay, 
ee ee = / 
iy mre on call. Returns a mae Peeeocer poe: a 
[* 2c ste es ot se este ss as ake tc ole ake ote ste ate We ate ate ste eats ote ate ate fe sic ate Ys ests mye Bae SE aR Oe / 


TICKET: PROCELURE(SFQUENCER) BYTE REENTRANT PUELIC; 
DECLARE SEQUENCER POINTER, 


SEQSID EYTE, 
VALUE WORD; 


me 





/* Lock the Active Process Table. */ 
DO WHILE LOCKSET(@APTSLOCK,119); 
END} 


/* Tdentify the sequencer. */ 
SEQSIB = LOCATESSEQ(SEQUENCER); 


/* First obtain value to be returned to the caller */ 
VALUE = SEQSTAELE(SEQSID) .SEQSVALUE; 


/* Then increment the value of the sequencer */ 
SECSTAPLE(SECQSID) .SECSVALUE = 
SEQSTABLE(SEQSID).SEQSVALUE + 13 


/* Unlock the Active Frocess Table */ 
APTSLOCK = @;3 


/* Return the value to the caller. */ 
RETURN VALUE; 
END; /* TICKET Procedure. */ 
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READ: PROCEDURE(EVENTCOUNT) BYTE REENTRANT PUBLIC; 
DECLARE EVENTCOUNT POINTER, 
eGo LD Bees, 
VALUE WORD; 


/* Lock the Active Process Table. */ 
DO WHILE LOCKSET(CAPTSLOCK,119); 
END} 


/* Identify the eventcount. */ 
EVCSID = LOCATESEVC(EVENTCOUNT ); 


/*® “Read the current value of the eventcount. */ 
VALUE = EVCSTABLE(EVCSID) .EVCSVALUE;} 


/* Unlock the Active Frocess Table. */ 
APTS 10Ciaa= ac; 


/* Return the current value to the caller. */ 
FETURN VALUE; 
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END; /* READ Procedure. */ 
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CREATESEVC: PROCEDURE(EVENTCOUNT) REENTRANT FUELIC; 
DECLARE EVENTCOUNT POINTER; 
DECLARE CHAR BASED NAME (6) BYTE; 
DECLARE I BYTE; 


/* Lock tne Active Process Table */ 
DO WEILE LOCKS=T(GAPTSLOCK ,119); 
END} 


IF /* The eventcount had not already been created */ 
LOCATESEVC(EVENTCOUNT) = NOTSFOUND TEEN 


DO; 
I = @; 
DO /* Copy the name into EVCSTABLE */ 
Reece (1) <> % ) AND {I < 5); 


/* Copy the character into the table. */ 
EVCSTABLE(EVENTS) .EVCSNAME(I) = CFAR(I); 


OND; /* While loop. */ 


/* Insert the delimiter °%’ in the pociole Vem tiny sa / 
EVCSTABLE( EVENTS) .EVCSNAME(I) = °S°3 


/* Increment EVENTS to indicate a new addition. */ 
EVGNTS = EVENTS + TI; 


* 


END; /* Create the eventcount. */ 


/* Unlock the Active Process Table. */ 
APTSLOCK = @; 


RETURN; 

END; /* CREATESSVC Procedure. */ 
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CREATESSEQ: PROCEDURE(SECUENCER) REENTRANT PUBLIC; 
DECLARE SEQUENCER POINTER; 
DECLARE CHAF EASED NAME (6) EBYTE; 
DECLARE I BYTE; 


/* Lock the Active Process Table */ 
DO WHILE LOCKSET(GAPT$LOCK,119); 
END; 


IF /* The sequencer had not already been created */ 
LOCATESSEG(SEQUENCER) = NOTSFOUND THE! 


DO; 
I = @3 
DO /* Copy the name into SHQSTABLE */ 
WHILE (CEAR(I) <> °%°) AND (I ¢< 5)3 


we 
42 


/* Copy tne character into the table. 
SECSTAELE (SEQUENCERS) .SECSNAME(I) = CEHAR(I)3 


END; /* While loop. */ | 


/* Insert the delimiter “%° in the table entry. */ 
SEQSTABLE(SEQGUENCERS) .SZOSNAME(I) = °%’; 


/* Increment SEQUENCERS to indicate a new addition. */ 
SEQUENCERS = SEQUENCERS + 13 


END; /* Create the Sequencer. */ 


/* Unlock the Active Process Table. */ 
APTSLOCK = @}3 


RETUEN; 
END; /* GREATESSEO Procedure. */ 
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CREATESPROCESS: PROCEDURE(PPBSFTR) REENTRANT PUELIC; 


DECLARE PPESPTR POINTER} 
DECLARE INITSSTACKSFRAME STRUCTURE 
(rh WORD, 
CS WORD, 
IP MHORD, 
ES WORD, 
DS WORD, 
AX WORD, 
Cx GORD, 
DX WORD, 
EX WORD, 
SI woORD, 
[TI woORL, 
RET WORD, 
ERP woORD, 
SP WORD); 
DECLARE INTERRUPT LITERALLY °1197;3 


/* Lock the Active Proce 


DO WEILE LOCKSET (@GAPTSLO 
END; 


/* Set up initializati 
INITSSTACKSFRAME. FL 
INITSSTACKSFRAME.CS 
INITSSTACKSFRAME.IP 
INITSSTACKSFRAME.ES 
INITSSTACKSFRAME.DS 
INITSSTACKSFRAME.AX 
INITSSTACKS FRAME. CY 
INITSSTACKSFRAME.DX 
INITSSTACKSFRAME. BX 
INITSSTACKSFRAME.SI 
INITSSTACKSFRAME. DI 
INITSSTACKSFRAME.RET = 
INITSSTACKS FRAME. EP 
INITSSTACESFRAME.SP 


7 Move initialization 
MOVB(GINITSSTACKSFFAME 


/* Enter process in Ac 
APT(PROCESSES ).STATE = 


$5 Table. */ 
@6,119); 


on stack frame. */ 
PROS PARAM.FL} 
PROCS PARAM.CS; 
PROSPARAM.IP; 
PROSPARAM.ES; 
PROSPARAM.DS;3 
PROSPARAM.AX; 
PROSPARAM.CX3 
PROS PARAM.DX; 
PROS PARAM. BX} 
PROSPARAM.ST} 
PROSPARAM.DI;3 
INTERRUPT; 

g; 

ea 


Stack frame into memory. 
,» PPB .DBE,2&); 


tive Process Table. */ 
PreEeobAls; 


APT(PROCESSES ).AFFINITY = PPB.AFFINITY; 


1st 


a, 
+" 





APT(PROCESSES).VPSID = NIL; 
APT(PROCESSES).PRIORITY = FPPB.PRIORITY; 
APT(PROCESSES ).EVCSVALUESAW = 23 
APT(PROCESSES).THREAD = NIL; 
APT(FROCESSES).DBR = PFE.DER; 


/* Enter process in the Loaded List ty priority */ 
FREV = NIL; 

NEXT = LOADSLIST(CFUSNUMBER) 3 

DO WHILE PPB.PRIORITY > APT(NEXT). PRIORITY; 


PREV = NEXT; 
NEXT = APT(NEXT).LOADSTHREAD; 
END; 


IF NEXT = NIL TEEN 
APT(PREV).LOADSTEREAD = ENTRY; 
ELSE 
IF NEXT = LOADSLIST(CPUSNUMBER) THEN 
DO; 
APT(ENTRY).LOADSTHREAD = 
LOADSLIST(CPUSNUMBER); 
LOADSLIST(CPUSNUMRER) = ENTRY; 
ELSE 
Dies 
APT(PREV).LOADSTHREAD = ENTRY; 
APT(ENTRY).LOADSTEREAD = NEXT; 
2ND; 


7/* Unlock the Active Process Table. */ 
Memo EOCK = 2; 


roTURN; 
END; /* CFEATESPROCSSS Procedure. */ 
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TCSPESHANDLER: PROCELURE REENTRANT PUBLIC; 
/* 
D 


Lock the Active Process Table. */ 
WHILE LOCKSET(GAPTSLOCK ,119);3 





END} 
CALL TCSSCFEDULER; 


/* Unlock the Active Process Table. */ 
APTSLOCK = @3 
RETUFN; 


END; /* TCSPESHANDLEP Procedure. */ 
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